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INTRODUGTION 

Here are the object record formats that define the object 
lanquaqe for the 8086 microprocessor. The 8086 object lanquaqe is 
the output of all lanquaqe translators with the 8086 as the tarqet 
processor. The 8086 object lanquaqe is input and output for object 
lanquaqe processors such as linkers, locaters, librarians, and 
debuqqers. 

The 8086 object module formats permit specification of 
relocatable memory imaqes that may be linked to one another. 
Capabilities are provided that allow efficient use of the memory 
raappinq facilities of the 3086 microprocessor. 

This section defines certain terms fundamental to 8086 R&L. 
The terms are ordered not alphabetically, but so you can read 
forward without forward references. 

DEFIN I TION of. TERMS 

OMF - acronym for Object Module Formats. 

R&L - acronym for Relocation and Linkaqe. 

MAS - acronym for Memory Address Space. The 8086 MAS is 1 meqabyte 
(1,048,576). Note that the MAS is distinguished from actual memory, 
which may occupy only a portion of the MAS. 

MODULE - an "inseparable" collection of object code and other 
information produced by a translator or by the LINK-86 proqram. 
When a distinction must be made, 

T-MODULE will denote a module created by a translator, such as PLM86 

or ASM-86, . , _ 

L-MODULE will denote a module created by (cross) LINK-36 VI . 3 or 

earlier versions, and 
R-MODULE will denote a module created by (8086 based) LINK-86 from 1 
or more constituent modules. (Note that modules are not "created" 
in this sense by LOCATE-86; the output module from LOCATE-86 is 
merely a transformation of the input module.) 

Two observations about modules must be made: 

1) Every module must have a name, so that the 8086 Librarian, 
LIB86, has a handle for the module for display to the user. (If 
there is no need to provide a handle for LIB86. the name may be 
null.) Translators will provide names for T-modules, orovidinq a 
default name (possibly the file name or a null name) if neither 
source code nor user specifies otherwise. 

2) Every T-module in a collection of modules linked toqether 
ouqht to have a different name, so that symbolic debuqainq systems 
(such as ICE-86) can distinquish the various line numbers and local 
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symbols^ This restriction is not required by R&L^ and is not 

enforced by it^ 

LOGICAL SEGMENT - (LSEG) - A contiguous reqion of memory whose 
contents are determined at translation-time (except for address- 
binding) . Neither size nor location in MAS are necessarily 
determined at translation-time: size^ although partially fixed, may 
not be final because the LSEG may be combined at LINK-time to other 
LSEG^s^ forming a single LSEG; location in MAS is usually determined 
at LOCATE'-time (although some translators may produce ••absolute** 
object code^ whose location is already determined). 

FRAME -- A contiguous region of 64K of MAS^ beginning on a paragraph 
boundary (i^eor on a multiple of 16 bytes) o This concept is useful 
because the content of the four 8086 segment registers define four 
(possibly overlapping) FRAME' S| no 16-bit address in the 8086 code 
can access a memory location outside of the current four FRAME^s. 

An LSEG is constrained to be no greater than 64Kr so that it 

can fit in a FRAME^ This means that any byte in an LSEG may be 

addressed by a 16-bit offset from the base of a FRAME covering the 

LSEG. 

PSEG - This term is equivalent to FRAME. Some people prefer "PSEG'' to 
^•FRAME^' because the terms' ^'PSEG*' and "LSEG'* reflect ^ the "physical" 
and "logical" nature of the underlying segments. 

FRAME "NUMBER -= Every FRAME begins on a paragraph boundary. The 
"paragraphs'' in MAS can be numbered ^ 1 , 2 ^ « ^ . , 65535. These numbers^ 
each of which defines a FRAME^ are called FRAME NUMBERS. 

PARAGRAPH NUMBER - This term is equivalent to ''FRAME NUMBER.*' 

PSEG NUMBER - This terra is equivalent to "FRAME NUMBER." 

PIC - acronym for Position Independent Code. A PIC module is a module 
where load addresses and register initialization values are 
specified relative to segment and group bases,, Wo fixups are 

allowed • 

LTL - acronym for Load-^Tiroe Locatableo An LTL module is similar to a 
PIC module except that base fixups are allowed o 

GROUP - a group is a collection of LSEG's defined at translation-time^ 

whose final locations in MAS have been constrained such that there 

will be at least one FRAME which covers (contains) every LSEG in the 
collectioHe 

The notation "Gr A(X,Y,Z)^° means that LSEG's X, Y and Z form a 
qroupp and that the group^s name is A^ 

The fact that X, Y and Z are all LSEG's in the same aroup does 
not imply any ordering of X, Y and Z in MAS ^ nor does it imply any 
contiguity betvieen X^ Y and Z. 
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In the PIC/LTL case, an LSEG is not allowed to be in more than 
one group (e.g. defining two groups such as Gr Gl (A^C^B) . and Gr 
G2(B^C^D) in the same module is not legal) •• Otherwise an LSEG, may 
be in more than one group. The existence of groups such as Gl and 
G2 is not sufficient to infer that A,B,C,D all lie within some 
single FRAME^, although they might. 

CANONIC - any location in MAS is contained in exactly 4096 distinct 
FRAME'S? but one of these FRAME'S can be distinguished in that it 
has a higher FRAME NUMBER than any other FRAME. This distinguished 
FRAME is called the canonic FRAME of the location. 

Thus^ if FOO is a symbol defining a memory location^ one may 
speak of the "canonic FRAME of F00^% or of ^'FOO's canonic FRAME". 
By extension^ if S is any set of memory locations^ then there exists 
a unique FRAME which has the lowest FRAME NUMBER in the set of 
canonic FRAME'S of the locations in S. This unique FRAME is called 
the canonic FRA.ME of the set S. Thus, we may speak of the canonic 
FRAME of an LSEG or of a Group of LSEG's. 

SEGMENT NAME - LSEG's are assigned names at translation-time. These 
names serve only 3 purposes: 

1) they play a role at LINK-time in determininq what LSEG's are 
combined with what other LSEG*s. 

2) they may be used at LOCATE-time to designate specific 
LSEG's* 

3) they are used in assembly source code to specify groups, 

CLASS NAME - LSEG's may optionally be assiqned Class Names at 
translation-time^ Classes define a partition on ^3EG*s: two LSEG's 
are in the same class iff they have the same Class Name. 

R&L associates no semantics with specific Class Namesi class 
semantics are completely user-defined. Examples of Class Naroes 
might be RED, BLUE, GREEN or ROM, RAM, DISPLAYMEMORYs 

The uses of Class Names include the first 2 uses of Segment 
Names above; additionally r Class Names give the user the power to 
identify many LSEG's by a single handle at LOCATE-time. 

OVERLAY NAME - LSEG's may optionally be assigned an Overlay Name at 
translation-time or at LINK-time. This name is specified when the. 
translator or LINK-36 is invoked, and all LSEG's within the same 
module will be assigned the same Overlay Name. 

An Overlay Name is similar to a Class Name in that it provides 
a handle on user-defined equivalence classes of LSEG^s^ Unlike 
Class Names, however. Overlay Naroes have semantics known by the 
LOCATE-86 program. (In brief, LSEG's in different overlays may be 
"located'' at overlapping MAS locations^) 
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COMPLETE- NAME -» The ''complete name" of an LSEG is defined to be the 
three component identification consisting of the Segment Name ^ Class 
Name and Overlay Name« LSEG's from different modules will be 
combined iff their Complete Names are identical « 
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MQ mj L S_I DE N TIF j CAT 1 N 

. In order to determine that a file contains an object program, a 
module header record will always be the first record in a module. 
There are three kinds of header records and each provides a module 
name. The additional functions of the header records are explained 
below. 

A module name may be generated during one of two processes: 
translation or linking. A module that results from translation is 
called a T-MODULE. A T-MODULE will have a T-MODULE HEADER RECORD 
(THEADR) . A name may be provided in the THEADR record by a 
translator. This name is then used to identify the source of all 
symbols and line numbers found in the T--MODULE. 

A module that results from linking is called an L-MODULE or an 
R-'MODULE. An L-MODULE will always have an L-MODULE HEADER RECORD 
(LHEADR). An R-MODULE will always have an R-MODULE HEADER RECORD 
(RHEADR) . In the LHEADR record or the RHEADR record a name may also 
be provided. This name is available for use as a means of referring 
to the module without using any of its constituent T-MODULE names. 
An example would be two T-MODULES, A and B, linked together to form 
R-MODULE C. R-MODULE C will contain two THEADR records and ^ will 
begin with an RHEADR record with the name C provided by the linker 
as a directive from the user. The R-MODULE C can be referred to by 
other tools such as the library manager without having to know about 
the originating module^s names, yet the oriainating module's names 
are preserved for debugging purposes. 

MODULE. ATTRIBUTES 

In addition to an optional name^ a module may have the 
attribute of being a main program as well as having a specified 
starting address. When linking multiple modules together r only one 
module with the main attribute should be given. The linker EPS 
specifies the result of finding two or more main modules. 

If a module is not a main module yet has a starting address 
then this value has been provided by a translator, possibly for 
debugging purposes. A starting address specified for a non-main 
module could be the entry point of a procedure, which may be loaded 
and initiated independent of a main program^ 

In summary, modules may or may not ^be main as well as may or 
may not have a starting address. 

SEGi^ENT DEFINITION 

A module is defined as a collection of object code defined by a 
seauence of records produced by a translator. The object code 
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represents contiguous regions of memory whose contents are 
determined at translation-time • These reqions are called LOGICAL 
SEGMENTS (LSEG's)o A module must contain information that defines 
the attributes of each LSEG. The SEGMENT DEFINITION RECORD (SEGDEF) 
is the vehicle by which all LSEG information (name^ lengthy memory 
alignment^ etCo) is maintained* The LSEG information is required 
when multiple LSEG^s are combined and when segment addressability 
(GROUPING, see below) is established. The SEGDEF records are 
required to follow the first header record (THEADR, or LHEADR, or 
RHEADR) . 

sj:gment_ addressing 

The 8086 addressing mechanism provides segment base registers 
from which a 64K byte region of memory, called a FRAME ^ may be 
addressed^ There is one code segment base reqister (CS) ^ two data 
segment base registers (DS^ ES) ^ and one stack segment base register 
(SS). 

The possible number of LSEG*s that may make up a memory image 
far exceeds the number of available base registers. Thus^ base 
registers may require frequent loading^ This would be the case in a 
modular program with many small data and/or code LSEG's* 

Hence the motivation to collect LSEG^s together to form one 
addressable unit that can be contained within a memory frame. The 
name for this addressable unit is a GROUP and has been defined 
earlier in the DEFINITION OF TERMS, 

To allow addressability of objects within a GROUP to be 
established r each GROUP must be explicitly defined in the module^ 
The GROUP DEFINITION RECORD (GRPDEF) provides a list of constituent 
segments either by segment name or by segment attribute such as "the 
segment defining symbol FOO^' or ''the segments vjith class name ROM^' ^ 

The GRPDEF records within a module must follow all SEGDEF 
records as GRPDEF records may reference SEGDEF records in defining a 
GROUPa The GRPDEF records must also precede all other records but 
header records as some R&L products must process them firsts The 
explicit ordering of records is given, latero 

SmBOLr DEimiTlOW 

Within a module there may be six different types of symbol 
definition recordSo The necessity for these records is based on two 
requirements s 1) references to externally defined symbols should 
be resolved by eauivalently defined symbols in another module 
(linking) and 2) attributes of locally defined symbols and line 
numbers should be made available for debugging purposes. 
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The requirements for symbol definition records for module 
linkinq is satisfied by the PUBLIC NAMES DEFINITION RECORD (PUBDEF) , 
the EXTERNAL NAMES DEFINITION RECORD (EXTDEF) , and the TYPE 
DEFINITION RECORD (TYPDEF) « Their semantics will be explained 

later. 

The requirements for debugging information are satisfied by the 
LOCAL SYMBOLS RECORD (LOCSYM) , the LINE NUMBERS RECORD (LINNUlH) , the 
DEBUG SYMBOLS RECORD (DEBSYM) , the BLOCK DEFINITION RECORD (BLKDEF) , 
the BLOCK END RECORD (BLKEND) , and the TYPE DEFINITION RECORD 
(TYPDEF). The association of the line numbers and local symbols to 
their original defining modules is essential and maintained by the 
THEADR record as explained earlier^ 

DATA 

The data that defines the memory image represented by a module 
is maintained in six varieties of DATA records. The DATA records 
are of three classes: relocatable^ physical^ and logical* 

There are two Relocatable DATA records s RELOCATABLE ENUMERATED 
DATA RECORD (REDATA) and RELOCATABLE ITERATED DATA RECORD (RIDATA) . 
Each relocatable DATA record is associated with a SEGDEF record or a 
FRAME number, and perhaps a GRPDEF Record o The SEGDEF record or the 
FRAME number, and the GRPDEF record provide information to determine 
the absolute address at which the data bytes are to be loaded^ The 
RIDATA record differs in that the data bytes are represented within 
a structure that must be expanded by the loader o The purpose of the 
RIDATA record is to reduce module size by encoding repeated data 
rather than explicitly enumerating each byte, as the REDATA record 
doeSo 

There are two Physical DATA records: PHYSICAL ENUMERATED DATA 
RECORD (PEDATA) and PHYSICAL ITERATED DATA RECORD (PIDATA) • The 
PEDATA and PIDATA records provide an absolute address at which the 
data bytes it contains are to be loaded* 

There are also tv#o Logical DATA records^ LOGICAL ENUMERATED 
DATA RECORD (LEDATA) and LOGICAL ITERATED DATA RECORD (LIDATA) . 
Each 'logical DATA record is associated with a SEGDEF record. The 
SEGDEF record provides information that allows the loqical DATA 
records to be converted to either Relocatable DATA records or 
Physical DATA recordSo 

Data bytes for all LSEG*s .are maintained in logical DATA 
records^ as an LSEG is either relocatable or it has been assigned an 
address (absolute) but has not been divorced from GROUP information* 

In summary r there are three classes of DATA records^ 

RELOCATABLE, PHYSICAL^ and LOGICAL^ The data bytes of the ^"unnamed 

absolute segment*" , divorced form all LSEG .and GROUP information / are 

found in PHYSICAL DATA RECORDS « Data bytes from all LSEG's, 
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absolute or relocatable^ are found in LOGICAL 
ENUtnERATED and ITERATED attributes within the 

of representing the actual data bytes^ 



DATA RECORDS. The 

classes are two ways 



A 8086 loader can load RDATA or PDATA Records; but will 
probably not be able to maintain the LSEG table information required 
for loading LDATA Records. Thus, Relocatable and Physical DATA 
records are sometimes called ''Loadable'' DATA records^ and Logical 
DATA records are called "Non-Loadable*' DATA records. 

INDICES 

Throughout the 8086-OMF speci f ication ^ "index" fields occur. 
An . index ' is an integer that selects some particular item from a 
collection of such items. (Exhaustive list of examples: NAME 
INDEX, SEGMENT INDEX, GROUP INDEX, EXTERNAL INDEX, TYPE INDEX, BLOCK 
INDEX.) 

(Note) An index is normally a positive number^ 
The index value zero is reserved, and may carry a 
special meaning dependant upon the type of index 
(e.g.f a Segment Index of zero specifies the "Unnamed, 
absolute pseudo-segment; a Type Index of zero 
specifies the "Untyped type^' (which is. different from 
"Decline to state")). (End of Note) 

In general r indices must assume values quite large (i.e.^ much 
larger than 255).. Nevertheless, a-great number of object files will 
contain no indices with values greater than 50 or 100. Therefore^ 
indices will be encoded in 1 or 2 bytes ^ as required! 

The high-order (left-most) bit of the first (and possibly the 
only) byte determines whether the index occupies one byte or two. 
If the bit is d, then the index is a number between and 127^ 
occupying one byte. If the bit is 1^ then the index is a number 
between and 32K-1^, occupying two bytes, and is determined as 
follows? the low--o.-rder 8 bits^ are in the second byte, and the high-- 
order 7 bits are in the first byte. 
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^ ^CEP TUAL F RAMEW QRK for FI XUP ^ 

A ''Fixup" is some modification to object code, requested ^ by a 
translator, performed by the R&L system, achieving address binding, 
(see Appendix 4 for Examples) 
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8086 and/or 8089 translators specify a fixup by giving four 
data; (1) the place and type of a LOCATION to be fixed up. (2) one 
of two possible fixup MODE'S, (3) a TARGET, which is a meroc ry 
address to which LOCATION must be made to refer, and (4) 
defining a context within which the reference takes place^ 



FRAME 



LOCATION 
OFFSET, 
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The vertical alignment of this diagram illustrates 4 points 
(remember that the high order byte of a word in 8086 memory is the 
byte with the higher address); (1) a BASE is merely the high order 
word of a pointer (and R&L doesn't care if the low order word of the 
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pointer is present or not); (2) an OFFSET is merely the low order 
word of a pointer (and R&L doesn't care if the high order word 
follov/s or not); (3) a HIBYTE is merely the hiqh order half of an 
OFFSET (and R&L doesn't Nare if the low order half precedes or not)? 
(4) a LOBYTE is merely the low order half of an OFFSET (and R&L 
doesn't care if the hiqh order half follows or not) • 

A LOCATION is specified by 2 data: (1) which of the above 5 
types the LOCATION is, and (2) where the LOCATION is. (1) is 
specified by the LOC subfield of the LOCAT field of the FIXUPP 
Record; (2) is specified by the DATA RECORD OFFSET subfield of the 
LOCAT field of the FIXUPP Record. 

MODE -- R&L supports 2 kinds of fixupss *' sel f-relative" and "segraent- 
relative'* « 

Self-relative fixups support the 8~ and 16-bit offsets that are 
used in the CALL, JUMP and SHORT-JUMP instruction's o Segment-^ 
relative fixups support all other addressing modes of the 8086. 

TARGET - The TARGET is the location in MAS beina referenced o (More 
explicitly^ the TARGET may be considered to be the lowest byte in 
the object being referenced o) A TARGET is specified in one of 8 
waySo There are 4 "primary" ways ^ and 4 ^'secondary*' ways* Each 
primary way of specifying a TARGET uses 2 data: an INDEX-=or-FRAMS- 
MUMBER 'X' p and a displacement 'D't 

(T0) X is a SEGMENT INDEX. The TARGET is the D'th byte in the 
LSEG identified by the INDEX. 

(Tl) X is a GROUP INDEXo The TARGET is the D^th byte followinq 
the first byte in the LSEG in the qroup that is eventually LOCATE 'd 
lowest in MAS« 

CT2) X is an EXTERNAL INDEXe The TARGET is the D'th byte 
following the byte whose address is (eventually) qiven by the 
External "Maine identified by the INDEXo 

(T3) X is a FRAME NUMBER. The TARGET is the O'th byte in the 
FRAME identified by the FRAME NUMBER (i.e.^ the address of TARGET is 

Each secondary way of specifying a TARGET uses only 1 datum: 
the IMDEX-or-FRAME«NUMBER X. An implicit displacement equal to zero 
is assumed : 

(T4) X is a SEGMENT INDEX. The TARGET is the ' th (first). byte 
in the LSEG identified by the INDEX. 

(T5) X is a GROUP INDEX. The TARGET is the 0'th (first) byte 
in the LSEG in the specified qroup that is eventually LOCATE'd 
lowest in MAS. 
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(T6) X ■ is an EXTERNAL INDEX. The TARGET is the byte whose 

address is (eventually qiven by) the External Name identified by the 
INDEX* 

{T7) X is a FRAME NUMBER. The TARGET is the byte whose 20--bit 
address is (X^16) . 

The following nomenclature is used to describe a TARGET: 

TARGET: SI(<seqment nanie>) ^<displaceraent> [T0] 

TARGET: GI (<qroup nar!!e>) p<displacef!ient> [Tl] 

TARGET: EI(<symbol naii!e>) ,<displacement> [T2] 

TARGET: <FRAME NUM3ER> ,<d i splacement> [T3| 

TARGETS SI(<segroent na!ne>) [T41 

TARGET! GI(<qroup name>) [T51 

TARGET^ EI(<symbol narne>) [T6] 

TARGET? <FRAME NUMBER> [T71 

Here are some examples of how this notation can be used: 
TARGET? SICCODE),1024 



TARGETS GI(DATAAREA) 

TARGET^ EI(SIN) 

TARGET: 8000H,24H 

TARGET: EI ( PAYSCHEDULE) ,24 



The 1025th byte in 
the seqraent "CODE'' 

the location in MAS of 
a group called "DATAAREA" 

the address of the external 
subroutine "SIN" 

MAS location 80024H 

the 24th byte following the 
location of an 
EXTERNAL data structure 
called "PAYSCHEDULE^^ 

Although '"TARGET? SI(A)^' and "TARGET^. SICA),0" both specify 
the same TARGET, their use can have different effects, ^ as^ is 
discussed below in the section on intermediate values in fixop 
ar ithraetic ^ 

FRAME - Every 8086 memory reference is to a location contained within 
some FRAME; where the FRAME is designated by the content of some 
segment reaister. In order for R&L to form a correct, usable memory 
reference/ it must know not only what the TARGET is, but also with 
•respect to which FRAME the reference is being made. Thus every 
fixop specifies such a FRAME, in one of 6 ways (F0,«oo,F5) described 
below. Some ways use a datum, X^ which is 
as above. Other ways require no datum« 



an INDEX-or-^FRAME-^NUMBER, 



This is not the case 
reference may be to any 
independently of FRAME. 



of an 8089 self-relative reference. The 

location within an 8089 proqram. 

The only restriction is that the 
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displacement between the LOCATION and the TARGET must be within 32K. 
To indicate this type of fixup^ a 7th way (F6) of specifying a frame 
is introduced^ 

Below is the description of the seven ways of specifying 
frames J 

(F0) X is a SEGMENT INDEX. The FRAME is the canonic FRAME of 
the LSEG defined by the INDEX. 

(Fl) X is a GROUP INDEX. The FRAME is the canonic FRAME 
defined by the group (i.e.^ the canonic FRAME defined by the LSEG in 
the group that is eventually LOCATE'd lowest in MAS). 

(F2) X is an EXTERNAL INDEX. The FRAME is determined when the 
External Name's public definition is found. There are 3 casess 

{F2a) The symbol is defined relative to some 
LSEGr and there is no associated Group. The LSEG's 
canonic FRAME is specified. 

(F2b) The symbol is defined absolutely, without 
reference to an LSEG^ and there is no associated 
Group. The FRAME is specified by the FRAME NUMBER 
subfield of the PUBDEF Record (a. v.) that gives the 
symbol's definition. 

(F2c) Regardless of how the symbol is defined i, 
there is an associated Group. The canonic FRAME of 
the Group is specified. (The group is specified by 
the GROUP INDEX subfield of the PUBDEF Record (q.v.) .) 

(F3) X is a FRAME NUMBER (specifying the obvious FRAME). 

(F4) No X. The FRAME is the canonic FRAME of the LSEG 
containing LOCATION. (If LOCATION is specified absolutely (i.e., in 
a PEDATA Record or a PIDATA Record (q.v.)), then it is not 
"contained" in an LSEG; in this case the FRAME is determined as in 
(F2) above, taking the FRAME NUMBER from the FRAME NUMBER field of 
the DATA Record. 

(F5) No X. The FRAME is determined by the TARGET. There are 4 

casesj 

(F5a) The TARGET specified a SEGMENT INDEXi in 
this case, the FRAME is determined as in (F0) above. 

(F5b) The TARGET specified a GROUP INDEX: in 
this case^ the FRAME is determined as in (Fl) above. 

(F5c) The TARGET specified an EXTERNAL INDEX: in 
this case^ the FRAME is determined as in (F2) above. 
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(F5d) The TARGET is specified with an explicit 
FRAME NUMBER: in this case the FRAME is determined as 
in (F3) above, 

(F6) No X. There is no FRAME. This is a way to indicate to 
R&L that an 8089 self-relative reference is to be processed. A 
signed displacement between the LOCATION 20-bit address and the 
TARGET 20-bit address must be computed. 

Nomenclature describing FRAME'S is similar to the above 
nomenclature for TARGET'S, viz: 

FRAME: SI(<seqroent name>) [^^1 

FRAME: GI(<qroup name>) C^l] 

FRAME: EI(<syi!ibol name>) [^2] 

FRAME: < FRAME NUMBER> [^3] 

FRAME: LOCATION fF4] 

FRAME: TARGET [F51 

FRAME: NONE tF6] 

In practice, for an 8086 memory reference, it is likely that 
the frame' specif ied by a self-relative reference will be the canonic 
FRAME of the LSEG containing the LOCATION, and the FRAME specified 
by a segment relative reference will be the canonic FRAME of the 
LSEG containing the TARGET. This will be further explained below. 

SELF-RELATIVE FIXUPS 

A self-^relative fixup operates as follows: A memory address is 
implicitly defined by LOCATION? namely the address of the byte 
following LOCATION (because at the time of a self-relative 
reference, the 8086 IP (Instruction Pointer) or the 8089 TP (Task 
block Program pointer) is pointing to the byte following the 
reference) ^ 

For 8086 self--relative references, if either LOCATION or TARGET 
are outside the specified FRAME, R&L gives a warninq. Otherwise, 
there is a unique 16--bit displacement which, when added to the 
address implicitly defined by LOCATION, will yield the relative 
position of TARGET- in the FRAME o 

For 8089 sel f^relative references (F6) , if TARGET is not within 
32K from LOCATION, R&L gives a warning. Otherwise, there is a 
unique 16-bit signed displacement between the LOCATION and the 
TARGET « 

If the LOCATION is an OFFSET, the displacement is added to 
LOCATION modulo 65536; no errors are reported. 

If the LOCATION is a LOBYTE, the displacement must be within 
the range {-128:127}, otherwise R&L will give a warninq. The 
displacement is added to LOCATION modulo 256o 
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If the LOCATION is a BASE, POINTER, or HIBYTE, it is unclear 
what the translator had in mind, and the action taken by R&L is 

defined by LINK-86 and/or LOCATE-86 EPS's. 

SEGMENT-RELATIVE FIXUPS 

A seqroent-relative fixup operates in the followinq way: a non- 
negative 16-bit number, FBVAL, is defined as the FRAME NUMBER of the 
FRAME specified by the fixup, and a signed 20--bit number ^ FOVAL^ is 
defined as the distance from the base of the FRAME to the TARGET. 
If this signed 20«-bit number is less than or greater than 65535^ 
then R&L will report an erroro Otherwise FBVAL and FOVAL are used 
to fixup LOCATION in the following fashion: 

(1) if LOCATION is a POINTER,' then FBVAL is added (modulo 
65536) to the high order word of POINTER^ and FOVAL is added (modulo 
55536) to the low order word of POINTERo 

(2) if LOCATION is a BASEp then FBVAL is added (modulo 65536) 
to the BASE; FOVAL is ignored o 

(3) if LOCATION is an OFFSET^ then FOVAL is added (modulo 
65536) to the OFFSETi FBVAL is ignored e 

(4) if LOCATIOM is a HIBYTE, then (FOVAL / 256) is added 
(modulo 256) to the HIBYTE? FBVAL is ignored. (The indicated 
division is *' integer division^' , i.eo, the remainder is discarded^) 

(5) if LOCATION is a LOBYTE, then (FOVAL modulo 256) is added 
(modulo 256) to the LOBYTE; FBVAL is ignored • 

INTERMEDIATE VALUES in FIXUP ARITHMETIC 

The 8086 Object Module Formats guarantee fixups in the sense 
that, if a TARGET can not be accessed from a LOCATIOM with the 
assumed FRAME^ then that failure can be detected and R&L can issue a 
warning message^ This checking is called ^'access \/er i f ication'" . In 
order to perform this checking, LINK--86 and LOCATE-86 need to retain 
intermediate values of its address arithmetic. These intermediate 
values are retained either in the DATA Record , or in the FIXUP 
Recorde The following diagram illustrates three cases: 
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< ._ in DATA Record > <-— in FIXUP Record > 

+__ 4. + + + 

I 4-n I or I 4-n I <null> < Case 1 

+ -.+ 4. — . — — + + 

4.^^„„-|. 4.-.^ 4.--* .-+ + • + . + 

I g I or I g II +n I < Case 2 



I q I or I q II n I < — - Case 3 

Case 1 illustrates the situation where a fixup is specified in 
a "secondary" way. No explicit displacement ^D' is provided in the 
FIXUP Record, so arithmetic must be done in the LOCATION itself |, in 
the DATA Record. As the diagram shows ^ the LOCATION may be a byte 
or a word. (If LOCATION is a POINTER, arithmetic is on each half 
separately^ so the above diagram applies separately to each half of 
a POINTER.) In Case 1, the value (s) in LOCATION are considered to 
be non-negative numbers (''-fn^') , and are considered to be equivalent 
to a specification of a displacement 'D'l thus the R&L access 
verification incorporates the value ''^n'^ ^ 

Case 2 illustrates the situation where a fixup is specified in 
a ''primary'' way. An explicit displacement ^D' is provided in the 
FIXUP Records This displacement is considered to be a non--neqative 
number ("4-n'')e When all arithmetic required by the fixup is 
complete^ the resultant value (in the FIXUP Record) is checked for 
validity by RSL, and then, finally^ that result is added {modulo 256 
or modulo 65536) t© the original content of LOCATION V'q'') The 
value ''g'' may be considered as non-negative^ or as signed 2^s 
complement! R&L doesn^t care because there is no checking in this 
final stage of the fixup. 

Case 3 is the same as Case 2, except that the displacement ^D', 
instead of being restricted to non-negative numbers in the range 
{0:65535} r may represent signed (2*s complement) numbers in the 
range f-1 , 048 , 576 : 1 , 048 , 575} • (Note: initially, this case will not 
be supported* It is designed into the formats for completeness: it 
allows support^ with R&L access verification^ of TARGET'S specified 
in a '"primary" way^ with negative displacements ®D^e) 

Here are some cases where a "primary" specification of a TARGET 
is necessary or desirables 

First, yet another definition; a ^'REFERENT'' is a memory 
location, with respect to which a TARGET is positioned* This is 
best made clear by an examples in the specification 

TARGET: EI (STRUCT) ,24 
the TARGET is the 24 'th byte after the location named "STRUCT" 1 the 
REFERENT is the location named ''STRfJCT" itself « 
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(1) A SHORT-JMP is being made to an exLernal subroutine« In 

this case, the TARGET should be specified as 

TARGET: EI (subroutine) ,0000fl 
The reason is that when LINK--86 learns where the subroutine is 
located, it will probably be a known offset (dl) within some LSEG A« 
Thus^ LINK--86 will convert the above TARGET to the form: 

TARGET: SI (A) ,dl ' 
■Now the proqramraer may be correct in •^knowing*' that when the program 
is eventually LOCATE'd^ the TARGET will be within 128 bytes of 
LOCATION? however, this does not mean that dl is less than 128! 
Thus, as LINK-86 maintains the (possibly changing) value of dl as 
various pieces of LSEG A are combined^ it needs a full word to 
maintain the offset. Since the LOCATION is a sinqle byte, the 
translator must provide an offset field in the fixup record itself 
fo-r LINK-86 to maintain intermediate fixup values. 

(2) The translator wishes to reference "backwards'' from the 
REFERENT. For example, if the TARGET is the word in front of the 
external array ARY, and the reference is with respect to a base 
register that will contain the address of the LSEG .named FOO, the 
translator would use 

FRAME: SI (FOG) 
' TARGET: EI (ARY) ,0000H 
and place the "negative offset^' FFFEH in LOCATION. R&L will perform 
access verification to the REFERENT ARY; however, access to the 
TARGET is not guaranteed, and is the programmer's responsibil ity o 

Note: if Case 3 in the above diagram were available, the 
translator could use 

FRAME: SI(FOO) 

TARGET: EI (ARY) ,-2 
and R&L would perform access verification^ not to the REFERENT ARY 
(as above), but to the actual TARGET (in front of ARY)! 

(2) (continued) The calculation by LOCATE-86 involves 3 
quantities: the MAS-location 'of FOO^ the .!^AS=-location of the ^LSEG 
(say^ BAZ) containing ARY, and the relative offset of ARY within 
BAZo LOCATE-86 can enforce thaf the final offset, which is the 
difference 

(location of BAZ, plus relatiy'.e offset) - (location of FOO) . 
is not greater than "65535, prdyided that all quantities entering 
into this difference are known. If the translator had specified the 
fixup as 

FRAME: SI(FOO) 

TARGET: EI (ARY) 
then LI^K-86 would have had to maintain the (possibly chanqinq from 
linkage to linkage) relative offset of ARY within BAZ. in the 
LOCATION itself p where it gets ^'added'* to the content FFFEB. And 
because the R^L system cannot know if the FFFEH was a negative 2 or 
a positive 65534^ the access verification of R^L may thwart the 
intentions e 
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The following example (3) is a case where access verification 
works whether the TARGET specification is ^'primary- or ^^secondary^^ s 

(3) The translator wishes to reference "forwards^^ from a 
REFERENT, and to ensure that the TARGET lies within the specified 
FRAME^ For example, we wish to reference the 100 ^th byte m an 
external structure STRCT. The translator may specify the fixop as 
FRAME: SI(FOO) 
TARGET: EI (STRCT) ,99 
R&L will ensure that the distance 
the 100 ^th byte of STRCT is 
constraint miqht be achieved even 
FRAME of FOO.) 



from the canonic FRAME of FOO to 
less than 5553^. (Note that this 
if STRCT lies outside the canonic 



(4) 
that a 



Bibyte fixups specified in a primary 
full word is used to accumulate 



m 

Only after LOCATE Ung 
used as a fixup value, 
truncation of low byte 
is LOCATE 'd. 



will the value of 
This prevents the 
before adding the 



ay will be correct 
the value of an offsets 
the hibyts of an offset be 
loss of accuracy due to 
address at which an object 
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RECORD ORDER 

A object code file must contain a sequence of {one or more) 
modules^ or a library containing zero or more modules^ A module is 
defined as a collection of object code defined by a sequence of 
object records^ The following syntax shows the valid orderings of 
records to form a module. In addition ^ the given semantic rules 
provide information about how to interpret the record sequence^ The 
syntactic description language used herein is defined in WIRTH: 
CACM, November 1977, v 20, n 11, p 822 - 823. 

object^file = sequence I library^ 

sequence = module {module} ^ 

= LIBHED {module} libtail. 

= tmod I Imod | rmod I omod ^ 



library 

module 

tmod 

Imod 

rmod 

omod 

sqr__table 

sqofe table 

seq. qrp 



= THEADR sqr. table 



{component} 



modtail ^ 



= LHEADR sgr. table {data} { t_component } modtail. 
= RHEADR sgr. table {data} { t_component } modtail. 

{o. component} o- modtail. 



= RHEADR sqor_table 

= seg.__grp [REGINT] . 

= seq.qrp {OVLDEF} [REGINTl . 

= {LNAMES} {SEGDEF} { TYPDEF | EXTDEF | GRPDEF }. 
Or- component = {data} { t_component} EMDREC. 
t^component = THEADR {cooiponent } • 
component = data 1 debug, record. 



data 



= content, def 1 thread_^def I 

TYPDEF I PU8DEF | EXTDEF, 



debug- record = LOCSYM ! LINNUM | DEBSYM I 

BLKDEF I BLKEMD ! ENDREC. 

content_def = data^record {FIXUPP}* 

thread_def = FIXUPP* (containing only thread fields) 

data_record = LIDATA | LEDATA ! PIDATA | PEDATA ! 

REDATA I RIDATA« 



c- modtail 



= {OVLDEF} modtail, 
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modtail = [REGINT] MODBND. 

libtail = LIBMAM LIBLOC LIBDIC. 

NOTE: The character strings represented by capital letters above 
are not literals but are identifiers that are further defined in the 
section defining the Record Formats. 

The following rules apply; 

1. A FIXUPP record always refers to the previous DATA record. 

2. The debug records have as their originating module the module 
named by the nearest preceding THEADR record. 

3. All LNAMES, SEGDEF, GRPDEF, TYPDEF^ and EXTDEF records must 
precede all records that refer to them. 

4. COMENT records may appear anywhere within a file^ except as the 
first or last record in a file or module, within a content^def, 
or within a libtail^ 

5. OVLDEF records may appear either immediately after the segment 
and group definitions or at the end (before the REGINT and 
HODEND records) , but not at both places. The number of OVLDEF 
records must be equal to the number of o_components ^ and the 
order of these records must be same as the Oi component order ^ 
the first OVLDEF record pointing to the 'root* part« 

6. As with the OVLDEF records, the REGINT record may appear either 
at the beginning of a module (after SEGDEF's, GRPDEF's, and 
OVLDEF's if any) or at the end (before the MODEND record), but 
there can not be two REGINT records in the same moduleo 
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JJTR0pUCTION, to, the. RECORD FORMATS 

The followinq paqes present diaqrams of Record Formats in 
schematic form. Here is a sample, to illustrate the various 
conventions: 

SAMPtE^RECORD..- FORMAT 
" "~ (SAMREG) " 

*********************•*///********* I I I I*********** 

* * * ^ * * 

* REC * RECORD * NAME * NUMBER * CHK * 

* TYP * LENGTH * * * SUM * 

* xxH * * * * * 

* * * * * * 

I I 

4. rpt + 

TITLE and OFF IC lAL _ABBRE VI AT ION 

At the top is the name of the Record Format Described, toqether 
with"an official abbreviation. To promote uniformity among various 
programs^ including translators^ debuggers^ the various R&L 
products^ and various tools such as EDOJ86 and OJED86, the 
abbreviation should be used in both code and documentation^ The 
abbreviation is always 6 letters. 

The^ BOXES 

Each format is drawn with boxes of two sizes. The narrow 
boxes^ outlined entirely with asterisks, represent single bytes. 
The wide boxes^ outlined entirely with asterisks, represent two 
bytes each. The wide boxes, outlined with asterisks, but with three 
slashes in the top and bottom^ represent a variable number of bytes, 
one or more^ depending upon content. The wide boxes^ outlined with 
asterisks^ but with four vertical bars in the top and bottom^ 
represent 4-byte fields. 

REC_ TYP 

The first byte in each record contains a value between and 
255f indicating which record type the record is* 

B SCORD LENGTH 

The second field in each record contains the number of bytes in 
the record, exclusive of the first 2 fields^ 

NAME 
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Any field that indicates a '^NAME^* has the following internal 
structure: the 1st byte contains a number between and 40, 
inclusive, that indicates the number of remaining bytes in the 
field. The remaining bytes are interpreted as a byte string; each 
byte must represent the Ascii code of a character drawn from this 
set: { ?P:._0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ }. Most 
translators will choose to constrain the character set more 
strictly; the above set has been chosen to ^'cover" that required by 
all current processors, 

NUMBER 

A 4-byte NUMBER field represents a 32-bit unsigned integer, 
where the first 8 bits (least-significant) are stored in the first 
byte (lowest address) , the next 8 bits are stored in the second 
byte f etc, 

REPEATED OR CONDITIONAL FIELDS 

Some portions of a Record Format contain a field or series of 
fields that may be repeated or more times. Such portions are 
indicated by the "repeated" or "rpt" brackets below the boxes. 

Similarlyr some portions of a Record Format are present only if 
some given condition' is true; these fields are indicated by similar 
''conditional'' or "cond" brackets below the boxes. 

CHK^SUM 

The last field in each record is a check sum, which contains 
the 2's complement of the sum (modulo 256) of all other bytes in the 
record. Therefore, the sura (modulo 256) of all bytes in the record 
equals 0^ 

BIT FIELDS 

Descriptions of contents of fields will sometimes get down to 

the bit level. Boxes outlined in asterisks, but with vertical lines 
drawn through them, represent bytes or words; the vertical lines 
indicate bi t 'boundar ies , thus the byte, represented below, has 3 
bit-fields of 3-, 1- , and 4-'bitsj 

* I I I I I I I * 

* II * 

* I I I I I I I * 
************************* 
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T-MODULE HEADER RECORD 



(THEADR) 



* * * * * 

* REC * RECORD * t * CHK * 

* TYP * LENGTH * MODULE * SUM * 

* 80H ^^ * NAME * * 

* * * * * 

***f?**^^'^*5V**^****^* €?***///**** ******* 



Every module output froni a translator must have a T-MODULE 
HEADER RECORDo Its purpose is to provide the identity of the 
original defining module for all line numbers and local symbols 
encountered in the module up to the follov/inq T--MODULE HEADER RECORD 
or MODULE END RECORiT . 

This reco.rd can also serve as the header for a module^ i.e^^ it 
can be the first record^ and will be for modules output from 
translators « 

T-MQD ULE NAME 

The T-MODULE NAME provides a name for the T-Module. 
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L^^Op ULE. HEADER. RE GORD 
(LHEADR) 

^^^*^^?f-?ff ************-* **///** ********* 
^ 1' * * * 

"- REC - RECORD * L-MODULE * CHK * 
* TYP - LENGTH * NAME * SUM * 
- 82H ^' * * * 

■i? ± * ^ fs 



Every module previously created by (cross) LINK-86 (Vlo3 or 
earlier) or by LOCATE-86 may have an L^MODULE HEADER RECORD. This 
record serves only to identify a module that has been ' processed 
(output) by LINK-86/LOCATE-86. When several modules are linked to 
form another module , the new module requires a name, perhaps unique 
from those of the linked modules, by which it can be referred to (by 
the LIB86 program^ for example) . 

L-MODULE NAME 

The L-MODULE NAME provides a name for the L-Moduleo 
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R-MQDULE HEADER RECORD 
(RHEADR) 

^ *^ ^ # * ^ ^ 

* REC * RECORD * R-MODULE ^ R==MODULE * R^MODULE * CHK * 

* TYP * LENGTH * NAME * ATTR ^^ INFO * SUM ^ 

* 6EH * * ^^ * * * 

* * * * ^ * * 



Every module created by LINK--86/LOCATE-86 may have an R-MODULE 
HEADER RECORD* This record serves to identify a module that has 
been processed (output) by LINK-86/LOCATE-86 . It also specifies the 
module attributes and gives information on memory usaqe and need. 
When several modules are linked to form another module, the new 
module requires a name^ perhaps unique from those of the linked 
modulesp by-which it can be referred to (by the LIB86 program^ for 
example) « 

R-MO DULE NA ME 

The R-MODULE NAME provides a name for the R-^Module* 

R-MQDULE ATTR 

The R-MODULE ATTR field provides information on various module 
attributes^ and has the following formats 

it is ± ^ * * 

^ MOD ^ SEGMENT *. GROUP * OVERLAY ^ OVERLAY * 

* DAT * RECORD ^ -RECORD ^ RECORD ^ RECORD * 

* * COUNT •. * ■ COUNT- "^^ COUNT ^ OFFSET * 

* * - * - ^ * * 
***********^*****'****-^*^^^**^#^ *************** ^-^j I 1 j*^^#?* 



The MOD DAT subfield has 'the following format: 

* I I I I ! 1 ! * 

*Z|2!Z!Z|ZiZ TYP * 

* ! I I I I I ! * 

Z^s indicates that these l--bit fields have not currently been 
assigned a function^ These bits are reauired to be zero^ 
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TYP is a 2-'bit subfield that specifies the module type. The 
semantics are defined as follows: 

TYP=0 The module is an absolute module^ 

TYP=1 The module is a relocatable module. Fixups 

other than base fixups may still be present. 
TYP=2 The module is a Position Independent Code module. 

It can be loaded anywhere^ No fixups are needed. 
TYP=3 The module is a Load-Time Locatable Module. 

It can be loaded anywhere with perhaps some base 

fixups to be performed • 

The SEGMENT RECORD COUNT subfield indicates the number of 
Segment Definition Records in the raodule« 

The GROUP RECORD COUNT subfield indicates the„ number of Group 
Definition Records in the module* 

The OVERLAY RECORD COUNT subfield indicates the number of 
Overlay De-finition Records in the module (including Overlay 
Definition Record for the 'Root'). 

The OVERLAY RECORD OFFSET subfield is a 4-byte fields It 

contains a 32-bit unsigned number indicating the location in bytes,, 

relative to the start of the object file, of the first Overlay 

Definition Record m the moduleo This field must be zero when 
OVERLAY RECORD COUNT is zerOo 

R^iMO DULE IMFO 

The R-MODULE INFO field contains a sequence of four 32-bit 
unsigned numbers specifying the different types and sizes (in bytes) 
of memory space that the module will need. It has the following 

fo rmat : 

^ ff 'is -^ ^ 

* STATIC * MAXIMUM * DY'MAi^IC * MAXIMUM * 

* SIZE ^ STATIC * STORAGE * DYNAMIC * 

* * SIZE * * STORAGE * 

* ^ * ^ ^ 

STATIC SIZE is the total size of the LTL segments in the 
module^ This is the minimum static memory space that must be 
allocated to the module so that the module can be loaded. 

MAXIMUM STATIC SIZE is the maximum total size of the LTL 
segments in the moduleo This value must be greater than or equal to 
STATIC SIZE. (By default MAXIMUM STATIC SIZE is set equal to STATIC 
SIZE) This value only aives the maximum space needed* Dependina on 
available memory, the loader may allocate any value between the 
STATIC SIZE and the MAXIMUM STATIC SIZE. 
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DYNAMIC STORAGE is the memory space that must be allocated (for 
buf f er r for dynamic expansion, etc..^ at load-time. The default 

value is zero. 

MAXIMUM DYNAMIC STORAGE is the maximum dynamic memory that 
miqht be needed by the module^ This value must be greater than or 
equal to DYNAMIC STORAGE (By default MAXIMUM DYNAMIC STORAGE value 
is set equal to DYNAMIC STORAGE value) . 
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LIST_ OF; NAMES. RECORD 
(LNAMSS)"'" 

-k fs ^ ^ fs 

* REC * RECORD * NAME * CHK * 

* TYP ^ LENGTH * ^ SUM * 
*9^[^* * ^^ ^ 

is is * fi * 

***^^*y^^*^^^^^********* / / / * * ^ * * ?^ ^^ ^ * '^ * 

! ! 

This Record provides a list of Names that may be used in 
followinq SEGDEF and GRPDEF Records as the names of Segments^ 
Classes, Overlays and/or Groups* 

The ordering of LNAMES Records within a module, together with 
the ordering of Names within each LNAMES Record, induces an ordering 
on the NameSo Thus^ these names are considered to be numbered i 1^ 
2, 3r 4, .«« These numbers are used as '^Name Indices" in the 
"Segment Name Index ^ Class Name Index p Overlay Name Index and Group 
Name Index fields of the SEGDEF and GRPDEF Records. 

NAME 

This repeatable field provides a name, which may have zero 
length . 
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SEGMENT D EFINIT ION- RE CORD 
(SEGDEF) 

************•*******•*///*** •*****^***** **///*******///*******///*** ******* 
*•** * * * * ** 

* REG * RECORD * SEGMENT * SEGiMENT * SEGMENT * CLASS * OVERLAY * CHK * 

* TYP * LENGTH * ATTR * LENGTH * NAME * NAME * NAME * SUM * 

* 98H * * * * INDEX * INDEX * INDEX * * 
^* * * • * * ** 

**********************///*****************///*******///*******///********** 

I I 

+ .Q onditiona 1- + 

SEGMENT INDEX values 1 through 32767, which are used in other 
record types to refer to specific LSEG's, are defined implicitly by 
the sequence in which SEGDEF Records appear in the object file. 
(SEGMENT INDEX is reserved to indicate the ^'unnamed absolute 
seqment*% which is not really a segments it is a possibly empty set 
of possibly disjoint regions of memory; it is normally created by 
LOCATE-86r although translators may create portions of it as well, 
if they wish.) 

SEG. ATTR 

The SEG ATTR field provides information on various attributes 
of the segment^ and has the following format; 

is***********i^^^*****^^^^^*^^*^i^************************ 

* * * ^ * * * 

* ACB * FRAME ^ OFF ^ LTL * MAXIMUM * GROUP ^ 

* P * NUMBER * SET ^ DAT * SEGMENT * OFFSET * 

^ * -k ^ -k LENGTH ^ ^ 

* * * k -k * ^ _ 
^#*±***^****^i^^^*^*#±^^*#^i^^^**^*********************** 

I I I 

4- conditional 4- ^ conditional + 

The ACBP byte contains 4 numbers, the A, C, B, and P attribute 
specifications. This byte has the following format; 

k'k-k*^*'k*k'kkiskk'k'kk'k-k-k^±-k:k-k-k'kk:k^-k'k'k 

* I I I I I I I * 

* A I c 1 B I p * 

* I I I I I ! I * 

■k±is'k-k'k-k-k-kis:k'k'k'kii*'k'k-kis'kk±'k'kisisis±±±-k± 

A (Alignment) is a 3-bit subfield that specifies the alignment 
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attribute of the LSEG. The semantics are defined as follows: 



A=0 

A=l 
A=2 
A=3 
A=4 
A=5 
A=6 



SEGDEF 
SEGDEF 
SEGDEF 

SEGDEF 
SEGDEF 
SEGDEF 
SEGDEF 
al igned 



describes an absolute LSEGa 

describes a relocatable^ byte aligned LSEG. 
describes a relocatable, word aligned LSEG. 
describes a relocatable, paragraph aligned LSEG. 
describes a relocatable^ page aligned LSEG. 
describes an unnamed absolute portion of MAS. 
describes a load-time locatable (LTL) , paragraph 
LSEG if not member of any groups 



In addition the value of A determines if one or several 
"conditional" fields will be presents If A=0 or A=5 then the FRAME 
NUMBER and OFFSET fields will be presents If A=6 then the LTL DAT, 
MAXIMUM SEGMENT LENGTH, and GROUP OFFSET fields will be present. If 
A05 then the three NAME INDEX fields will be presento 



C (Combination 
combination attr ibute 
must have combination 
combined like C=6 bel 
OFFSET'S match (For 
For relocatable segme 
or 7 indicating how t 
of this attribute is 
combined: Let X,Y 
the combination of X, 
and let MXY denote th 
gap required between 
alignment attribute 
(combined) LSEG Z ;. le 
and let dy similar 
following table gives 
offsets dx' and dy' 
dy in Y: 



) is a 3-^bit subfield that specifies the 

of the LSEGo Absolute segments (A^0 or A^5) 

zero (C^0)o In this case the segments will be 

ow if and only if their FRAME HUMBERTS and 

A=0 their complete names must match as well) . 

nts, the C field encodes a number 0,lp2^4^5^6 

he segment may be combined. The interpretation 

best given by considering how two LSEG's are 

and let Z be the LSEG resulting from 

and LY be the lengths of X and Y, 

e maximum of LX,LY. Let G be the length of any 

the X- and Y-components of Z to accommodate the 

of Y. Let LZ denote the length of the 

(0<=dx<LX) be the offset in X of 

be the offset in Y of a byte. 

lenqth LZ of the combined LSEG Z, 

for the bytes corresponding to dx 



be 

Y. 



LSEG's, 
Let LX 



t dx 
ly 

the 
in Z 



a byte , 
Then the 
and the 
in X and 



C 

2 
4 
5 
6 



LZ 

LX+LY+G 

LX+LY 

LX4-LY 

MXY 

MXY 



dx^ 

dx 

dx 

dx+LY 

dx 



dy^ 

dy+LX+G 
dy 

dy+LX 
dy 



dx+MXY-LX dy+MXY-LY 



The above table has no lines for 
indicates that the relocatable LSEG may not 
same combination semantics as C=6 ^ 
the LSEG so that LOCATE-86 will (in 
above all other LSEG's in MAS 
seament semantics of 8080 R&L) ; C=3 



C=0, C=l or C=3. C=0 
be combined; C=l has the 
but additionally "distinguishes" 
the default case) place the LSEG 
(this corresponds to the MEMORY 
is undefined. 



B (Big) is a 1-bit subfield which^ if 1. 
Segment Length is exactly 64K (65536). In 
LENGTH field must contain zero. 



indicates that the 
this case the SEGMENT 
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p (Page-Resident) is a 1-bit subfield which^ if 1^ demands that 
the segment be located in MAS without crossing a page boundary^ 
(This corresponds to the "in-page** relocation type of 8080 R&L^ 

The FRAME MUMBER and OFFSET fields (present only for absolute 
segments, A=0 or A=5) specify the placement in MAS of the absolute 

segment. The range of OFFSET is constrained to be between and 15 
inclusive. If a value larger than 15 is desired for OFFSET then an 
adjustment of the FRAME MUMBER should be done. 

The LTL DAT subfield (present only for LTL segments^ A=6) 
specifies the attributes of an LTL segment. It has the following 

format : 

* I I ! I ! ! I * 

*G|Z|ZiZ|Z|Z|Z IBSM* 

* I I 1 ! I ! I * 

Z's indicate that these 1-bit fields have not currently been 
assigned a function. These bits are required to be zero. 

G (Group) is a 1-bit field that^ if 1^ specifies that the 
segment is a member of a group^ and should be loaded as a part of 
the group^ 

BSM (Big Segment Maximum Length) is a 1-bit field that^ if 1, 
specifies that the maximum segment length is exactly ^4K« In this 
case the MAXIMUM SEGMENT LENGTH must contain zero. 

The MAXIMUM SEGMENT LENGTH subfield (present only for LTL 
segments^ A=6) specifies the maximum length in bytes of the LTL 
segment. (The purpose of this field is to provide information to a 
loader as to reserve memory space as much as possible up to the 
value in this fields) This value roust be greater than or equal to 
the value in the SEGMENT LENGTH field. The MAXIMUM SEGMENT LENGTH 
field is only big enough to hold numbers from to 64K-1 inclusive^ 
The BSM attribute bit in the LTL DAT field (see above) must be used 
to give- the segment a MAXIMUM length of 64K. 

The GROUP OFFSET subfield (present only for LTL segments i, A=6) 
gives the offset of the first byte of the segment , relative to the 
base of- the parent groups It must be zero if the G bit is 0^ This 
value will be used by the loader to determine the location relative 
to the group base.,of the^data records belonging to the segment® 

SEGMENT LENGTH 

The SEGMENT LENGTH field gives the length of the segment in 
bytes. The length may be zero; if so^ LINK-86 (unlike LINK-80) will 
not delete the segment from the module. The SEGMENT LENGTH field is 
only big enough to hold numbers from to 64K-1 inclusive. The 3 
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attribute bit in the ACBP field (see above) must be used to give the 
segment a length of 64K^ 

SEGMENT MAME INDEX 

The Segment Name is a name the programmer or translator assigns 
to the segment. Examples: CODE, DATA, TAXDATA, MODULENAME_CODE , 
STACK. This field provides the Segment Name, by indexing into the 
list of names provided by the LNAMES Record (s). 

CLASS. NAME INDEX 

The Class Name is a name the programmer or translator can 

assign to a segment, (If none is assigned ^ the name is null ^ and 

has length 0.) The purpose of Class Names is to allow the 

programmer to define a "handle'' by which several LSEG's. may be 
referred to (e.g. at LOCATE-time) by a single reference. Examples? 

RED^ WHITEp BLUBi ROM, FASTRAM ^ DISPLAYRAM. This field provides the 

Class Name ^ by indexing into the list of names provided by the 
LNAMES Record (s) . 

0¥ERLAY M A M E__IN DE X 

The Overlay Name is a name the translator and/or LINK-'86^ at 
the programmer's behest ^ apply to a segment. The Overlay Name ^ like 
the Class Name ^ may be nullo This field provides the Overlay Name p 
by indexing into the list of names provided by the LNAMES Recordfsje 

(Note) Tha "Complete Name" of a segment is a 3"-- 
component entity comprising a Segment Name ^ a Class 
Name and an Overlay Name. (The latter 2 components 
may be null.) (End of Note) 
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GROUP DEFINITI ON RECORD 
(GRPDEF) 

^ * ^ ^ - ^ ^ 

* REC * RECORD * GROUP * GROUP * CHK * 

* TYP * LENGTH * NAME * COMPONENT ^ SUM * 

* 9AH * * INDEX ^ DESCRIPTOR ^ * 

* * * ^ ^ * 

I I 

+-- repeated— + 

GROUP .NAME INDEX 

The Group Name is a name by which a collection of 1 or more 
LSEG's may be referenced. The important property of such a group is 
that, when the LSEG's are eventually fixed in MAS, there must exist 
some FRAME which contains (or ^'covers^') every LSEG of the qroup* If 
this is not the case, LOCATE^86 will issue a warning message. 

The GROUP NAME INDEX field provides the Group Name, by indexing 
into the list of names provided by the LNAMES Record (s). 

GROU P^ COMPON ENT_ DESC RI PTOR 

Each GROUP COMPONENT DESCRIPTOR has 1 of the following formats: 

^^^^^•kis^^^^ /// ^^"^^^ 

* ^ ^ 

* SI * SEGMENT ^ 

* ^ INDEX * 
*(FFH)^" * 

^* _ f-r is 

***********///***** 

* .;■ * ■ • , ' * 

* EI * EXTERNAL * 

* '■ *. INDEX * 

*('FEfl)* * 

* * * 
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* * * * * 

* SCO * SEGMENT * CLASS * OVERLAY * 

* * NAME * NAME * NAME * 
*(FDH)* INDEX * INDEX * INDEX * 



* 
* 
* * * * ^ 



* * ^ * * 

* LTL * LTL * MAXIMUM ^ GROUP * 

* GRP * DAT * GROUP ^ LENGTH * 
*(FBH)^ * LENGTH * * 

* ^ ^ * * 



***********************^^ 



* ^ 
FRAME * OFF ^ 
NUMBER * SET * 

* * * ^ 

****** *-***************^^^ 



* * 

* ABS * 

* GRP * 
*(FAH)* 



These 5 kinds of DESCRIPTOR'S are now discussed: 

If the first byte of the DESCRIPTOR contains 0FFH^ then 
DESCRIPTOR, contains 1 more field, which is a SEGMENT INDEX 
selects the LSEG described by a preceding SEGDEF record. 



the 
that 



If the first byte of the descriptor contains 0FEHp then the 
DESCRIPTOR contains 1 more field, which is an EXTERNAL INDEX that 
selects the LSEG that is (eventually) found to contain the specified 
External Name. 



(Note) If the definition of the External 
(eventually) found to be physical instead of 
(ieeop the External is defined with 
rather than an LSEG) , then an 



Index is 

logical 

respect to a PSEG 

error in group 



specification has occurred. (End of note) 



DESCRIPTOR contains 
which are Name 



0FDH, 
Index 



If the first byte of the 
DESCRIPTOR contains 3 more fields ^ 

which determine one or more Segment Name{s) , Class Narae(s) , 
Overlay Mamefs), respectively. This DESCRIPTOR allows a 
or programmer to include in a qroupr one 
separate translations (for which SEGMENT INDEX'S cannot be known) 



then the 

fields ^ 

and 

translator 

or more LSEG's from 
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A Name Index with value zero carries special significance: it 
specifies all_ Names^ (Note: Name Indices with zero value may not 
occur in other record types.) 

If the first byte of the DESCRIPTOR contains 0FBHp then the 
DESCRIPTOR contains 3 more fields, which are the LTL DAT field, the 
maximum length of the groups and the length of the groups This 
descriptor, if present ^ must precede all other descriptors in the 
records There may be at most one descriptor of this type in a 
GRPDEF record. There may not be any absolute component in the 
group. A segment can not be in two such groups^ 

The LTL DATA field has the following format: 

********************************* 

* !! I I I I 1 * 

*Z!Z1Z!Z!Z|Z IBGLIBGM* 

* I ! I ! ! I I * 

*^****#*******^**^**********^**** 

Z's indicate that these 1-bit fields have not currently been 
assigned a function^ These bits are required to be zeroa 

BGL (Big Group Lenqth) is a l-^bit subfield that, if 1, 
specifies that the Group lenqth is exactly ^4Ke In this case the 
GROUP LENGTH subfield must contain zeroo 

BGM (Big Group Maximum Lenqth) is a I'-bit subfield that, if 1, 
specifies that the maximum group length is exactly 64K« In this 
case the MAXIMUM GROUP LENGTH subfield must contain zeroo 

The GROUP LENGTH subfield specifies the length of the group 
that has been determined after the Group is ''located'', and the 
seqments in the group arc put in contiguous meraory area. All fixups 
have been performed relative to the base of the Groupe 

The MAXIMUM GROUP LENGTH subfield specifies the maximum length 
of the group that has been determined after the Group is "located", 
using the raaximum lengths of the segment componentSo 

If the first byte of the DESCRIPTOR contains 0FAH, then the 
DESCRIPTOR contains the address of the Group* Once a Group has been 
LOCATEd , it has an address chosen by LOCATE--86, relative to which 
ail fixups have been performed « If fixups relative to the Group 
base are required after LOCATE-86 has assigned an address to the 
Group then the FRAME NUMBER should be used as the baseo The address 
of the Group is also available for debugging systems such as ICE. 
If a Group has been assigned an address by LOCATE-86 then it is 
absolute and this descriptor must precede all other descriptors in 
the records There may be at most one descriptor of this type in a 
GRPDEF record. 
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(Examoles) Assume that an LNAMES record exists such that the 
names "DATA% "RAM", '^MYPROG% "CODE". ^* ^* (null), ^-STACK% ^^CONST^' 
and "MEMORY", are selected by Name Index values of 1^ 2, 3, 4^ 5^ 6, 
7 and 8^ respectively^ 

The Descriptor with 4 fields: [0FDH, 3, 1, 1] specifies the 
LSEG with Segment Name '•MYPROG^*, Class Name '^DATA^' , and Overlay Name 
^^DATA" . 

The Descriptor with fields: [0FDH, 3^ Ir 5] specifies the LSEG 
with Segment Name ^'MYPROG" . Class Name "DATA", and no (or ^null^, or 
"unspecified") Overlay Name. 

The Descriptor with fields: (0FDH, 3, 1, 01 specifies any and 
all LSEG's with Segment Name "MYPROG" and Class Name ^«DATA% 
regardless of their Overlay Name(s). 

The PLM-86 compiler will be able to inform LOCATE-86 of the 
*'Small*' assumptions by emitting 2 GRPDEF (Group Definition) Records? 
one contains the single descriptor [0FDH, 4, 4^ 51. the other 
contains the descriptors [0FDH, 1, 1, 51. [0FDH, 6. 6, 5], 
[0FDH, 7r 7, 51, and [0FDH, 8, 8, 51. (End of Examples) 
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TY PE_ DE FI NIT ION RECORD 
(TYPDEF) 

*************•**■********///****•*****///************ 

* * * * * ^ 

* REC ^ RECORD * NAME * EIGHT * CHK ^ 

* TYP * LENGTH * (LINK86 * LEAF * SUM * 

* 8EH ^ * USE) * DESCRIPTOR * ^ 

* ^ * * * * 

*^^^^^^^^***************/y/******^^^///^^* ******* ^* 

I I 

+— —rpt--^ — + 

This record provides the description of the type of an object 
or objects presumably named by one or more names provided in PUSDEF^ 
EXTDEF, BLKDEF, DEBSYM and/or LOCSYM records. The type is described 
as a Branchf which consists of a sequence of Leaves^ The types 
supported^ and the corresponding branches^ are provided in an 
appendix « 

As many "EIGHT LEAF DESCRIPTOR*' fields as necessary are used to 
describe a branch. (Every such field except the last in the record 
describes eight leaves; the last such field describes from one to 
eight leaves^) 

TYPE INDEX values 1 through 32767, which are contained in other 
record types to associate object types with object names^ are 
defined implicitly by the sequence in which TYPDEF records appear in 
the object file. 

Use of this field is reserved for LINK-86. Translators should 
place a single byte containing in it (which is the representation 
of a name of length zero) ^ 

EIGHT_ LEAF DESCRIPTOR 

This field can describe up to eight Leaves. If more than eight 
Leaves are to be represented, the field may be 'repeated as 
necessary. Unless the last leaf is a Repeat Leaf (see below) , the 
Branch is deemed to end in an indefinite sequence of easy null 
leaves. This field has the following format: 

* * * 

* E ^ LEAF * 

* N * DESCRIPTOR * 

* * * 

* * * 

***** 1^ * ir ***///***** * 

I I 

+ rpt + 
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The EN field is a bytes the 8 bits, left to riqht, indicate if 
the following 8 Leaves (left to right) are Easy (bit=0) or Nice 
{bit=l) . 

The LEAF DESCRIPTOR fields which occurs between 1 and 8 times ^ 
has one of the following formats? 

ik is -k -k -k -k -k 
k k 

k k 

k to * 

* 128 * 

k k 

kkkkkkk 

kkkkkkkkkkitkkkkkkkk 
k k k 

k k Q k 

* 129 * to * 
k k 64K-'l * 

* * * 

kkkkkkkkkkk/^/kkkkk 

k k k 

k k k 

* 130 * NAME * 

* * k 
k k k 
kkkkkkk kk kk ^ / /kkkkk 

kkkkkkkkkkk///kkkkk 
k k k 

k k k 

* 131 * INDEX * 

k k k 

k k k 

kkkkkkkkkkk///kkkkk 

kkkkkkkkkkkkkkkkkkkkkkkkk 
k k * 

k k * 

* 132 * to * 

* * 16M-1 * 

k k * 

itkkkkkkkkkkkkkkkkkkkkkkkk 
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* * ■ 

* 133 * 

* * 

^ *********** * 

* * * 

* *-127 * 

* 134 * to * 

* *+127 * 

* * * 

************* 

******************* 

* * * 

* * -.32K * 
■■* 135 * to * 

* * +32K * 

* * * 

******************* 

****************************** 

* * * 

* i^ 4-byte signed * 

* 136 ^ integer * 

* * * 

* * * 

****************************** 

The single byte i, containing a value between and 128 
represents a Numeric Leaf or a Null Leaf, If the value is 128. it 
represents a Null Leafo If the value is less than 128^ it 
represents a Numeric Leaf with the indicated inteqer number o 

The second form, with a leading byte containing 129 ^ represents 
a Numeric Leafo The number is contained in the following 2 bytes « 

The third form, v;ith a leading byte containing 130, represents 
a String Leaf a The field following the leading byte represents the 
string/in OMF's standard representation o 

The fourth form^ with a leading byte containing 131 ^ represents 
an Index Leafo The field following the leading byte represents an 
Index, which is" a number between Q and 32K-,. ^ in OMF's standard 
representation. Recursively defined types are allowed. 

The fifth form, with a leading byte containing 132, represents 
a Numeric Leaf^ The number is contained in the following 3 bytes. 
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The sixth form^ a single byte of 133, is a Repeat Leaf. A 
Repeat Leaf can only occur as the last leaf of a Branch. If the 
last leaf of a branch is a Repeat Leaf then the previous leaf is 
considered to repeat indefinitely. Otherwise the Branch is 
considered to end in an indefinitely lonq sequence of easy Null 
leaves ^ 

The seventh form, with a leading byte containing 134^ 
represents a Signed Numeric Leaf. The number is' contained in the 
following byte, which will be signed extended if neccessary. 

The eighth form, with a leading byte containing 135r represents 
a Signed Numeric Leaf. The number is contained in the following 2 
bytes r signed extended if neccessary^ 

The ninth form, with a leading byte containing 136, represents 
a Signed Numeric Leaf. The number is contained in the following 4 
bytes ^ signed extended if necessary. 
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PUBLIC NAMES DEFINITION RECORD 
(PUBDEFT 

**********i^*^*****^*^^^///*******^^///±^***i^***** **********///*** ******** 
** * * * * ** 

* REC * RECORD * PUBLIC * PUBLIC * PUBLIC * TYPE * CHK * 

* TYP * LENGTH ^ BASE * NAME ^ OFFSET * INDEX * SUf4 * 
*g0p|* * * * * *^* 

** * * * * ** 

***********^**^*** *****///*********///*********************///*** ******** 



-repeated- 



This record provides a list of 1 or more PUBLIC NAME'S; for 
each one,. 3 datums are provided: (1) a base value for the name^ (2) 
the offset value of the name, and (3) the type of entity represented 
by the name^ 

PUBLIC ^BASE 

The PUBLIC BASE has the following format; 

****•///***•** **:^/ //**** *^ *********** 

* ^ * * 

* GROUP * SEGMENT * FRAME * 

^ INDEX * INDEX * NUMBER * 

* " * ■ ^ * 

-k * * * 

*****///#******•*///***************** 

I I 

+conditional+ 

The GROUP INDEX field has a format qiven earlier, and provides 
a number between ar^d 32767 inclusive. A non-zero GROUP INDEX 
"associates" a group with the public symbol^ and is used as 
described on paqe 16^. case (F2c)-. A zero GROUP INDEX indicates that 
there is no associated; qroup^ 

The SEGMENT INDEX field- .has. a format qiven earlier^ and 
provides a number between and 32767 inclusive^ 

A non-zero SEGMENT INDEX selects an LSEG^ in which case the 
location of each public symbol defined in the record is taken as a 
non-neqative displacement (qiven by a PUBLIC OFFSET field) from the 
first byte of the selected LSEG, and the FRAME NUMBER field must be 
absents 

A SEGMENT- INDEX of (leqal only if GROUP INDEX is also 0) 
means that the location of each public symbol defined in the record 
is taken as a displacement from the base of the FRAME defined by the 
value in the FRAME NUMBER field. 
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(Informal Discussion) The FRAME NUMBER is present iff 
both the SEGMENT INDEX and GROUP INDEX are zero. 

A non-zero GROUP INDEX selects some qroup; this group 
is taken as the "frame of reference" for references to all 
public symbols defined in this record, e .q . , LINK-86 and 
LOCATE-86 will perform the following actions: (1) Any 
fixup of the form: 

TARGET: EI(P) 
FRAME: TARGET 
(where *'P" is a public symbol in this PUBDEF record) will 
be converted by LINK-86 to a fixup of the form: 

TARGET: SI(L) ,d 

FRAME: GI (G) 
where *'SI(L)^' and ^'d" are provided by the SEGMENT INDEX 
and PUBLIC OFFSET fields. (The "normal" action would have 
the frame specifier in the new fixup be the same as in the 
old fixup, viz.: FRAME: TARGET.) (2) When the value of a 
public symbol, as defined by the SEGMENT INDEX. PUBLIC 
OFFSET-r and (optionally) FRAME NUMBER fields^ is converted 
to a {base^of fset} pair, the base part will be taken as 
the base of the indicated group. (If a non-neqative 16- 
bit offset cannot then complete the definition of the 
public symbol's value^ an error will occur.) 

A GROUP INDEX of zero selects no qroup. LINK-86 will 
not alter the FRAME specification of fixups referencing 
the symbol, and LOCATE-86 will take^ as the base part of 
the absolute value of the public symbol, the canonic frame 
of the segment (either LSEG or PSEG) determined by the 
SEGMENT INDEX field. (End of Informal Discussion) 

PUBLIC^NAME 

The PUBLIC NAME field gives the name of the object whose 
location in MAS is to be made available to other modules. The name 
must contain 1 or more characters^ 

(Note) R&L's only cdnstraint upon the characters 
in names is that they lie within the range 20H (space) 
through 7EH (tilde) inclusive. Other characters may 
be usedr but may produce awkward results when output 
to listing devices, etc^ 

However r translators may proscribe the admissible 
character set more strictly. (End of Note) 

PUBLIC OFFSET 

The PUBLIC OFFSET field is a 16-bit value, which is^either the 

offset of the Public Symbol with respect to an LSEG (if SEGMENT 

INDEX > 0) r or the offset of the Public Symbol with respect to the 

specified FRAME (if SEGMENT INDEX = 0). 
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TYPE INDEX 

The TYPE INDEX field identifies a single precedinq TYPDEF (Type 
Definition) Record containing a descriptor for the type of entity 
represented by the Public Symbols 
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EXTERNAL.: NAMES- DEFINITION RECORD 
(EXTDEF) 

***********************///*^* ******///*** ******** 

* * * * * * 

* REC * RECORD * EXTERNAL * TYPE * CflK * 

* TYP * LENGTH * ' NAME * INDEX * SUM * 

* 8CH * * * * * 

* * * * * * 

*************•*********///*********///*********** 



-repeated- 



This Record provides a list of external naraes^ and for each 
such namep the type of object it represents. LINK-85 vjill assign to 
each External Name the value provided by an identical Public Mame 
(if such a name is found) . provided that the two names name objects 
of the same type^ 

EXTER.NAL_NAME 

This field provides the name^ which must have non-zero length, 
of an external object. 

Inclusion of a Name in an External Names Record is an implicit 
request that the object file be linked to a module containinq the 
same name declared as a Public Symbol o This request obtains whether 
or not the External Name is actually referenced within some FIXUPP 
Record in the module. 

The order inq of EXTDEF Records within a module, toqether with 
the orderinq of External Names within each EXTDEF Record, induces an 
order inq on the set of all External Names requested by the . modulee 
Thus. External Names are considered to be numbered? 1^ 2^ 3, 4^ oo« 
These numbers are used as '^External Indices'' in the TARGET DATUM 
and/or FRAME DATUM fields of FIXUPP Records, in order to refer to a 
particular External Name. The format of an External Index has been 
given earliero 

(Caution) .8086 External Names are numbered 
positively! 1,2,^3,... This is a change from 3080 
External Names, which were numbered starting from 
zero: 0,1,2, s«o The reason is to conform with other 
8086 Indices (Segment Index, Type Index, etCo) which 
use as a default value 'with special meaning. (End 
of Caution) 

External indices may not be forward referrinq. That is to say^ 
an external definition record defining the k'th object must precede 
any record referring to that object with index k. 
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TYPE. INDEX 

This field identifies a single precedina TYPDEF (Type 
Definition) Record containing a descriptor for the type of object 
named by the External Symbol* 
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LOCAL. SyiHBOLS- RECORD 
(LOCSYM) 

***********************///*********///*********************/// 

** * * * * ** 

* REC * RECORD * LOCAL * LOCAL * LOCAL * TYPE * CHK * 

* TYP * LENGTH * SYMBOLS * SYMBOL * SYMBOL * INDEX * SUM * 

* 9 2H * * BASE * NAME * OFFSET * ^ * 
** * * * * ** 
***********************///*********///*********************///*********** 

I I 

4..^ — _««.-.„ — - — '-repeated— ■ — — + 

This record provides information about symbols that were used 
in the source program input to the translator which produced the 
module. The purpose of this information is to aid ICE and other 
debugg inq prog rams ^ 

The information provided by the LOCSYM record is processed but 
not used by the R&L products* 

The symbols in the record were originally defined in a source 
module of name given by the most recently preceding T-MODULE HEADER 

records 

LOC AL_ S YM B LS^ BASE 

The LOCAL SYMBOLS BASE has the following format: 

*****///*********///* ^* ************** 

* * * * . 

* GROUP * SEGMENT * FRAME * 

* INDEX ^ INDEX * NUMBER * 

* * * * 

* * * * 
*****///*********///***************** 

I I 

+condi tional+ 

The LOCAL SYMBOLS BASE provides two things: (1) it gives a 
"referent'' value (location in MAS), with respect to which the value 
(location in MAS) of every symbol in the record will be defined by 
giving, for each symbol in the record, a non-negative offset; and 
(2) it gives an indication to LOCATE^86 as to how the final (20-^bit) 
values of the symbols should be decomposed into {base .offset} pairs. 

The referent value is given by the SEGMENT INDEX or by the 
FRAME NUMBER. If the SEGMENT INDEX field contains a number greater 
than 0, then the referent value is the location of the canonic frame 
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of the LSEG specified by the SEGMENT INDEX. (There must be no FRAME 
NUMBER field in this case.3) If both the GROUP INDEX field and the 
SEGMENT INDEX field contain zero, then the next field is a FRAME 
DUMBER; in this case^ the referent value is the location of the 
first byte of the specified frarne^ 

If the GROUP INDEX is zero^ the base v#ill be the canonic frame 
of the LSEG specified by the SEGMENT INDEX (if non-zero) , or by the 
FRAME NUMBER (if SEGMENT INDEX field contains zero) « If the GROUP 
INDEX is non-zero, the base will be the canonic frame of the Group 
specified by the GROUP INDSXo (If the value of a symbol cannot be 
described with respect to such a base^ then LOCATE-86 will give a 
warning • ) 

(Note) When GROUP INDEX is > 0, then one must also 
have SEGMENT INDEX > 0* (End of note) 

This field provides the name of the symbol. 

LOCAL SYMBQL^ OFFSET 

The LOCAL SYMBOL OFFSET is a 16-bit value, which is either the 
offset of the Local Symbol with respect to an LSEG (if SEGMENT INDEX 
> 0) ^ or the offset of the Local Symbol with respect to the 
specified FRAME (if SEGMENT INDEX = 0)o 

TY^E^JNDEX 

The TYPE INDEX field identifies a single preceding TYPDEF 
Record containing a descriptor for the type of entity represented by 
the Local Symbol . 
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LINE NUMBERS RECORD 
(LINNUM) 

-k ± * * ^ # ^ 

* REC ^ RECORD * LIME ^ LINE ^ LIME ^ €HK * 

* TYP ^ LENGTH * NUMBER * NUMBER * NUMBER ^ SUM -^ 

* 94H * * BASE * * OFFSET ^ ^ 

* * * * * ^ ^ 



-repeated- 



This record provides the means by v/hich a translator may pass 
to a debugger program^ the correspondence between a line number in 
source code and the corresponding translated code^ 

Since several independent source modules^ with independent line 
numbering, may be linked to form a single module^ a full 
identification of a source text line must include both its number p 
and also the name of the original containing module^ . The latter 
identification is provided by the previous T-MODULE BEADER Record e 

y^^ ^^^^^^^^^^^ 

The LINE NUMBER BASE has the following formats 

^^ is ^ * 

^ GROUP ^ SEGMENT * FRAME * 

^ INDEX "^ INDEX ^ NUMBER * 

* * ■ * ^ 

. * * * -k 

! I 

+condi tional4' 



The LINE NUMBER BASE has the same format and interpretation as 
the LOCAL SYMBOL BASE described for the LOCSYM records The SEGMENT 
INDEX and (if present) the FRAME NUMBER fields determine the 
location of the first byte of code corresponding to some source line 
number. This location may be physical (SEGMENT INDEX is 0) or 
logical (SEGMENT INDEX is non-zero) . The value of the GROUP IMDEX 
fields if non-zero I. informs LOCATE-8^ what base-^part to use for 
describing the finals 20=-bit location of the code lineo An example 
shows the use of a non-^zero Group Index s A translator knows that 
the code segment it is compiling is but one LSEG of many in a Group^ 
and thus references to pieces of the code segment are fixed up under . 
the assumption that the appropriate segment register contains the 
location of the base of the groups At debug time^ the user may tell 
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ICE-86 to '^'GO TO LINE NUMBER 22 OF MODULE MODNAME^' . ICE-86 may 
respond by executing a long jump to the appropriate location. This 
long jump will set the CS register; it is important that, the ^ CS 
register be set in accordance with the assumptions made while 
translating the code. This is the purpose of the GROUP INDEX field. 

LINE ; NUMBER 

A line number between and 32767^ inclusive, is provided in 
binary by this field. The high order bit is reserved for future use 
and must be zero^ 

LIN E^ N UMBER_ OFFSET 

The LINE NUMBER OFFSET field is a 16-bit value, which is either 
the offset of the line number with respect to an LSEG (if SEGMENT 
INDEX > 0) r or the offset of the line number with respect to the 
specified FRAME (if SEGMENT INDEX = 0). 
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B LOGK_DE F IN IT I ON_R ECORD 
(BLKDEF) 

***********************///**********///*** ******///*********///*^** ******** 
** * * * *** 

* REG * RECORD * BLOCK * BLOCK * PROCEDURE * TYPE * CHK * 

* TYP * LENGTH * BASE *INFORMATION*INFORiV|ATION* INDEX * SUM * 

* 7AH * * * * * ^ * 
^ • * * * * * * * 

********** *********^***///**********///*********///*********///******^^^^** 

+condi tional+ 

This record provides information about blocks that were defined 
in the source program input to the translator which produced the 
module. A BLKDEF record will be generated for every procedure and 
for every block that contains variables. The purpose of this 
information is to aid ICE and other debugging programs. 

The information provided by the BLKDEF record is processed but 
not used by the R&L products^ 

The block in the record was originally defined in a source 
module of name given by the most recently preceding THEADR record. 

BLOCK INDEX values, used in the DEBSYi^ record, are defined 
implicitly by the sequence of BLKDEF records in the T-»MODULE. 

BLOCK BASE 

The BLOCK BASE has the following formats 

a -k -k -k 

^ GROUP * SEGMENT ^ FRAME * 

* INDEX * INDEX ^ NUMBER ^ 

i, * k k 

^ k k k 

^^'k-kk///ii-kk*k*i€'kk///-kkk-kk-kkiiisii'kis-kk'kk± 

I I 

4-conditional-f 

The BLOCK BASE has the same format and interpretation as the 
LOCAL SYMBOL BASE described for the LOCSYM record. 
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BLOCK INFORMATION 

The BLOCK INFORMATION block has the followinq format; 

*****///*** ************************** 

* * - * * 

* * BLOCK * BLOCK * 

* NAME * OFFSET * LENGTH * 

* * • * * 

* * * * 
*****///***************************** 



NAME 

This field contains the name of the block. If the record 
describes an unnamed block in the source code (e«q. a DO block with 
no label in PL/H) the NAME will be of lenqth 0, 

BLOCK^OFFSET 

The BLOCK OFFSET is a 16-bit value which is the offset of the 
1st byte of the block with respect to the referent value specified 

by the^ BLOCK BASE. 

This field gives the lenqth of the block in bytes. 
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PROCEDURE__ IN F ORM A T ION 

The PROCEDURE INFORMATION block has the followinq format: 

^ I I I I ! I I - " 

^ I ! I ! I I I ^ RETURN ^ 

^P! L! 10 10 10 10 10* ADDRESS * 

^ j I I I I I I * OFFSET * 

* i I I I I I I * * 

+«, — .^ . — -condi tional '=--='—•=---— ^■•-^•^---f 

The P (Procedure) bit, if 1, indicates that the BLKDEF record 
was generated from a procedure in the source. The RETURN ADDRESS 
OFFSET is present only if P^la 

The L (LONG) bit tells vjhether the return address is- a 4»byte 
value (CS and IP) or a 2--byte value (IP only) a 

L=0 -> 2--byte return address 
L=l -> 4-'byte return address 

If P=0 the L bit has no meaning and is required to be" 0« 

The RETURN ADDRESS OFFSET, a 16--bit value, is the byte offset 
(from BP) of the procedure's return address in the procedure's 
activation record on the stacks 

T YPE__ I ^1 DE X 

The TYPE INDEX field identifies a sinqle preceding TYPDEF 
record containing the type descriptor for the procedure or block 
name. This field is present only if the NAME is non-zero* 

(Note) Symbols defined in BLKDEF records 
should not be repeated in DEBSYr4 records. (End of 
Note) 
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BLOCK END RECORD 
(BLKEND) 

* * * * 

* REC * RECORD * CHK * 

* TYP * LENGTH * SUM * 

* 7CH * * ^ 

* * * * 

************************* 



This record, together with the BLKDEF record^ provides 
information about the scope of variables in the source program. 
Each BLKDEF record must be followed by a BLKEMD record. The order 
of the BLKDEF. debuq symbol records, and BLKENDs should reflect the 
order of declaration in the source module^ 

(Note) For translators whose variables don't have 
scope (e.q* ASM86) the ordering of the records 
need not reflect the order of declaration in the 
source module^ (End of Note) 
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oebug. symsols , record 
Ydebsym) 

^ ^ ^ * 1^ * * ^ 

* REC * RECORD ^ FRAME ^ SYI^BOL * * TYPE ^ CHK ^ 

^ TYP ^ LEMGTH * INFORMATION^ NAME ^ OFFSET ^ INDEX * SUM ^ 

^ 7£H * ^ ^ ^ ^ .* ^ 

i, ^ a -^ ^ * * ^ 



4. ^ — repeated- 



This record provides information about all local syrobols 
including stack and based symbols. The purpose of this information 
is to aid ICE and other debuqqinq prograras« 

The information in this record is processed but not used by the 
R^L products. 

The symbols in the record were originally defined in a source 
module of name given by the most recently preceding T-»MODULE HEADER 
record ^ 

The scope of the symbols in the record is defined to be the 
block of the most recently preceding BLKDEF whose extent has not yet 
been closed by a BLKEMD. If no such BLKDEF exists the symbols are 
global to the source module of name given by the most recently 
preceding THEADR. 

ERA WE. INFORMATION 

This field gives information about the frame of the symbols 
defined in the record. It's format is as follows t 

-k* * * * * -k ^ -M -k ± y / / * -k -k -k * 
* k k 

* FRAME* * 

^INFO * DATUM * 

;* k k 

k k k 

kkkkk-kkkk* k J f Jk k * * * 

The FRAME INFO byte has the following format; 

•k kk k-k k kk kkk kkkkkkkkkkkkkkkkkkkkkk 

1 I I I I I 1 * 

* B I L I I I ! FRAME * 

* I I I I I METHOD * 
********************************* 
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The B (Based) bitr if 1^ means that the location in f^AS defined 
by the FRAME IMFORMATION and OFFSET fields contains a value that is 
the address of a symbols 

The L (Long) bit tells the length of this value ^ 

L=0 -> 2 bytes 
L=l -> 4 bytes 

If L=0 the frame part of the symbol address is defined to be 
the frame given by the FRAME INFORMATION field. 

If B=0, the location defined by the FRAME INFORMATION and 
OFFSET fields is the location of the symbol. In this case the L 
bit has no meaning and is required to be 0^ 

The FRAME METHOD field defines what kind of data is in the 
DATUM field. 

If FRAME METHOD=0, the DATUM has the format: 

* * * > * 

* GROUP * SEGMENT * FRAME * 

* INDEX * INDEX * NUMBER * 

* • * * * 

* * * * 

I I 

+condi tional+ 

The interpretation of the DATUM fields in the above format is 
identical to the interpretation of the LOCAL SYMBOLS BASE in the 
LOCSYM record. 

If FRAME METH0D=1, the DATUM has the format: 

* * 

* EXTERNAL . * 

* INDEX * 

* * 
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If FRAME METH0D=2^ the DATUM has the formats 

^ ' * 

^ BLOCK * 

* INDEX ^ 

* * 

* * 

FRAME METHODS o f 3 to 7 are illegal. 

The FRAME METHOD field also specifies what kind of information 
is in the OFFSET field (see below) . 

SYMBOL NAME 

This field provides the name of the symbol. 

OFFSET 

The OFFSET field contains a 16-bit value which is interpreted 
as follows : 

If FRAME METHOD is then this field is the offset with respect 
to the FRAME NUMBER or SEGMENT specified by the DATUM of the FRAME 
INFORMATION field. 

If FRAME METH0D=1 then this field is the byte offset from the 
external symbol specified by the DATUM of the FRAME INFORMATION 

field. 

If FRAME METH0D=2 then this field is the byte offset (from BP) 
in the activation record of the block specified by the DATUM of the 
FRAME INFORMATION field. 

TYPE INDEX 

The TYPE INDEX field identifies a sinqle preceding TYPDEF 
record containing a descriptor for the type of entity represented by 
the symbol. 

(Note on LOCSYMs) A DEBSYM record whose FRAME 
INFO field is is exactly equivalent to a LOCSYM 
record. (End of Note on LOCSYMs) 
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RELOQhTABLE SN UME R AT ED DAT A_ R j:C OHg 

Iredata) 

-k # * ^ * ilr * 

^ REG * RECORD ^ DATA * DATA * DAT * CHK ^ 
# TYP * LENGTH * REGORD ^ RECORD * * SUM * 
^ 72H * * BASE ^ OFFSET * ^ * 

^ ir * * ^ # * 

I I 

This record provides contiquous data from v^hich a portion of an 
80^86 memory image may eventually be constructed « The data may be 
loaded directly by an 8086 loader^ with perhaps some base fixups* 
For this reason the record may also be called Load-'Time Locatable 
(LTL) Enumerated Data Record* 

The data provided in this record may belong to any LSEG or 
Group or it may be assigned absolute 8036 memory addresses and be 
divorced from all LSEG/Group information. The data in this record 
is subject to modification by FIXUPP records^ if any^ which follow. 

This record may be generated by translators or (8086 based) 
LIlsrK-86 to produce loadable modules r and will be converted to PSDATA 
record by the L0GATE-86 program. 

DAT'A^ REGORD BASE 

The DATA REGORP BASE has the following formats 

# * #**///** it # ife is± * * /// * ** * * * * * * * * * * * * * * 

# * * * 
^ GROUP * SEGMENT * FRAME * 

# INDEX * IMDaX * NUMBER ^ 

is *■ . . * * 

a ^* ■ . . *■ # 

# # * * if/jy^ * is ^ is is is is itj//^ ****** * * * * * * * * * * 

I 1 

-i^conditional-i- 

The DATA RECORD BASE specifies the base relative to which the 
final address of the data record may be defined. It has the same 
format and interpretation as the LOCAL SYMBOL BASE described for the 
LOGSyM record. 

DATA REGORD OFFSET 

This field specifies an offset of the first byte of the DAT 
field either with respect to an LSEG (if SEGMENT INDEX > 0) or with 
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respect to the specif iad FRAME (if SEGMENT INDEX = 0> « Successive 
data bytes in the DAT field occupy successively higher locations of 
memory* 

DAT 

If one or more FIXUPP records follow then this field provides 
up to 1024 consecutive bytes of load-time locatable or absolute 
data. Otherwise^ the repeated field is constrained only by the 
RECORD LENGTH field. 

(Note on data record size) All data bytes in a 
data record must be within the frame specified by the 
data record. This is true for all 6 data record types 
(REDATA, RIDATA, PEDATA, PIDATA, LEDATA^ LIDATA) . 
(End of Note on data record size) . 
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RELO G^TABLS . ITERATED. DATA. RECORD 
("R I DATA) 

## 1^ lir ^ ife *# ^ ^ 1^ * 1^ :^ ^ *# 1^* ** ^ #///* ^ # ^ #*# ^ 1^ ^ ^ # ^ **# *<^ * i^ *///^ ^ ******** ^ 
* * * * * * * 

^ REG ^ REGORD * DATA * DATA ^ ITERATED * CHK * 
^ TYP * LENGTH ^ REGORD ^ REGORD ^ DATA * SUM * 

^ 74H ^ ^ BASE * OFFSET ^ BLOGK * * 

** *' *' * ** 

***********************///*********************///*********** 

! I 

+-repeated~+ 



This record provides contiauous data from which a portion of an 
8086 memory image may eventually be constructed ^ The data may be 
loaded directly by an 8086 loader^ with perhaps some base fixups^ 
For this reason the record may also be called Load-Time Locatable 
(LTL) Iterated Data Record. 

The data provided in this record may belonq to any LSEG or 

Group or it may be assigned absolute 8086 memory addresses and be 

divorced from all LSEG/Group information^ The data in this record 

.is subject to modification by FIXIJPP records^ if any^ which follow. 

This record may be generated by translators or (8086 based) 
LINK-36 to produce loadable modules, and will be converted to RIDATA 
record by the LOGATE-86 program. 

DATA REGORD BA S E^ 

The DATA REGORD BASE has the following format: 

* * * * 

* GROUP * SEGf^ENT * FRAME * 

* INDEX * INDEX * NUMBER * 

* * * * 

* * * * 
*****///*** ******///*** *^^*****^^^**^ 

I i 

+condi tionaH- 

The DATA REGORD BASE specifies the base relative to which the 
final address of the data record may be defined^ It has the same 
format and interpretation as the LOCAL SYMBOL BASE described for the 
LOGSYM record. 

DATA REGORD OFFSET 



This field specifies an offset of 
ITERATED DATA BLOGK field either with 



the first byte of the 
respect to an LSEG ( if 
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SEGMENT INDEX > 0) or with respect to the specified FRAiME (if 
SEGMENT INDEX = 0) . ^.Successive data bytes in the ITERATED DATA 
BLOCK field occupy successively higher locations of memory^ 

ITER ATED DATA BLOCK 

This repeated field is a structure specifying the repeated data 
bytes^ It is a structure that has the following formats 

^ *********# ^ ** ^ ****** ^* *** ir 1^ ^///± ^ * ^ * 
^ * * * 

* REPEAT * BLOCK * * 

^ COUNT * COUNT * CONTENT * 

* * * * 

* * * * 
*****************************///***** 



REPEAT ^CqU NT 

This field specifies the number of times that the CONTENT 
portion of this ITERATED DATA BLOCK is to be repeated. REPEAT COUNT 
must be non-zero.. 

^^^CK^CqUNT 

This field specifies the number of ITERATED DATA BLOCKS that 
are to be found in the CONTENT portion of this ITERATED DATA BLOCK. 
If this field has value zero then the CONTENT portion of this 
ITERATED DATA BLOCK is interpreted as data bytes. If non-zero then 
the CONTENT portion is interpreted as that number of ITERATED DATA 
BLOCKS. 

CONTENT 

This field may be interpreted in one of two ways, depending on 
the value of the previous BLOCK COUNT field. 

If BLOCK COUNT is zero then this field is a 1 byte count 
followed by the indicated number of data bytes. 

If BLOCK COUNT is non-zero then this field is interpreted as 
the first bvte of another ITERATED DATA BLOCK. 



(Note) From the outermost levels the number of 
nested ITERATED DATA BLOCKS is limited to 17^ i.e., 
the number of levels of recursion is limited to 17. 
(End of Note) 
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PHYSICAL ENUME RAT ED DATA RECORD 
(PEDATA) 

******** ^ * ^ ^ ^ lir ^ * ife * W ** ^ 1^ ^ ir ** lir 1^ ***** il^ 

* * * * * * * 

^ REC ^ RECORD * FRAME ^ OFF ^ * CHK * 

* TYP * LENGTH * DUMBER * SET * DAT ^ SUM ^ 

* g4g * ^ * * * * 

* * * * * * * 

************************* *:^*^if***********^*^***'^* 

I I 

-f-^rpt--^ 

This record provides contiguous data^ from which a portion of 
an 8085 memory imaqe may be constructed « The data belongs to the 
''unnamed absolute segment" in that is has been assigned absolute 
8086 memory addresses and has been divorced from all LSEG 
information. The data is subject to modification by FIXUPP records^ 
if any I, which follow. If there are FIXUPP records following, then 
the RECORD LENGTH is constrained to be less than or equal to 1028. 

This record may be generated by translators to produce a 
loadable absolute data record and will be also generated by LOCATE-- 
86. 

FRAME NUMBER 

This field specifies a Frame Number relative to which the data 
bytes will be loaded. 

OFFSET 

This field specifies an offset relative to the FRAME NUMBER 
which defines the location of the first data byte of the DAT field. 
Successive data bytes in the DAT field occupy successively higher 
locations of memory. The value of OFFSET is constrained to be in 
the range to 15 inclusive. If an OFFSET value greater than 15 is 
desired then an adjustment of the FRAME NUMBER should be done. 

DAT 

If one or more FIXUPP records follow then this field provides 
up to 1024 consecutive bytes of an 8036 memory image. Otherwise^ 
the repeated field is constrained only by the RECORD LENGTH field. 
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PHYSICAL ITERATED D ATA RECORD 
(PIDATAr 

* * ' ^ * * * * 

* REC * RECORD * FRAME * OFF * ITERATED * CHK * 

* TYP * LENGTH * NUMBER * SET * DATA ^ SUM * 

* 86H * * * * BLOCK * * . 

* ^ * # * ^ * 

I I 

^-.j-epeated — + 

This record provides contiquous data, from which a portion of 
an 8086 memory image may be constructed^ It allows initialization 
of data segments and provides a mechanism to reduce the^size^of 
object modules when there are repeated data to be used to initialize 
a memory image. The data belongs to the "unnamed absolute segment*' 
in that it has been assigned absolute 8086 memory addresses and has 
been divorced from all LSEG information. The data is subject to 
modification by following FIXUPP records if any. If there are 
FIXUPP records then the ITERATED DATA BLOCK length is constrained to 
be less than 1025. 

This record may be generated by translators to produce a 
loadable absolute data record and will be also generated by LOCATE- 
86. 

FRAME MUMBER 

This field specifies a frame number relative to which the data 
bytes will be loaded. 

OFFSET 

This field specifies an offset relative to the FRAME NUMBER 
which defines the location of the first data byte in the ITERATED 
DATA BLOCK. Successive data bytes in the ITERATED DATA BLOCK occupy 
successively higher locations of memory. The range of OFFSET is 
constrained to be between and 15 inclusive. If a value larger 
than 15 is desired for OFFSET then an adjustment of FRAME NUMBER 
should be done^ 

I T E RATED DATA/ g LOG K 

Same as for RIDATA record. 
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LQGICAL ENUMERATED DATA. g EC ORD 
(LED AT A) 

is is # W -k ie * 

* REC * RECORD ^ SEGiMEMT * ENUMERATED^ ^ CHK ^ 

# TYP ^ LENGTH * INDEX ^ DATA * DAT ^ SUM * 
^ A0H ^ ^ * OFFSET a -k is 

^ -k # ^ . lir * # 

'k'k-kis'kisisisisii'k^'k'k-k^is-k'kis*'k-'k///is-k*-kis'kisisii'kis-k'k-k^isisisis*-kis-kis1s-kisis'k 

I t 

-f-»rpt--4- 

This record provides contiguous data from which a portion of an 
8086 memory image may eventually be constructed* The data will 
probably NOT be loaded directly by an 8086 loader as it must be 
further processed by the 8086 R&L products. 

The data provided in this record may belong to any . LSEG^ The 
BASE portion of the address in the case of an absolute segment will 
be found in the SEGMENT DEFINITION RECORD specified by the SEGMENT 
INDEX« If the SEGMENT INDEX specifies a segment whose aliqnment 
attribute is not absolute then the data provided by this record is 
relocatable*, 

This record may be converted to a REDATA RECORD by the (8086 
based) LINK-86 program and will be converted to a PSDATA RECORD by 
the LOCATE-86 prog ram « 

SEGME NT IND EX 

This field must be non-zero and specifies an index relative to 
the SEGMENT DEFINITION RECORDS found previous to the LEDATA RECORD. 
The SEGMENT DEFINITION RECORD may specify that the data is absolute 
as one of the attributes of the segments In this case a Frame 
Number is provided in the SEGDEF records Absolute data must be able 
to be placed into LEDATA RECORDS so that grouping of relocatable 
LSEG^s with absolute LSEG^s can be achieved^ 

ENUMERAT_ED DATA. OFFSET 

This field specifies an offset that is relative to the base of 
the LSEG that is specified by the SEGMENT INDEX and defines the 
relative location of the first byte of the DAT field. Successive 
data bytes in the DAT field occupy successively higher locations of 
memory. If the SEGMENT INDEX specified an absolute LSEG then the 
offset is relative to the Frame Number provided in the correspondinq 
SEGDEF RECORD. 

DAT 
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This field provides up to 1024 consecutive bytes of relocatable 
or absolute dat:a« 
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LQGIGAL ITERATED DATA RECORD 
(LIDATA) 

* ^ • ^ * -k -k 

* REC * RECORD ^ SEGMENT * ITERATED * ITERATED ^ CHK ^ 

* TYP * LENGTH * INDEX ^ DATA * DATA ^ SUM ^ 

* A2H * 1^ * OFFSET * BLOCK * * 

^ ^ * 1^ ^ -^ ^ 



+- repeated — + 



This record provides contiquous data^ from which a portion of 
an 8086 memory image may eventually be constructed. The data will 
probably NOT be loaded directly by an 8086 loader as it must be 
further processed by the 8086 R^L products. 

The data in this record may belona to any LSEG. The BASE 
portion of the address in the case of named absolute data^ will be 
found in the SEGDEF record specified by the SEGMENT INDEX. If the 
SEGMENT INDEX specifies an LSEG other than an absolute LSEG then the 
data provided by this record is relocatable. 

This record may be converted to a RIDATA RECORD by the (8086 
based) LINK-86 program and will be converted to a PIDATA RECORD by 

the LOCATE-86 program. 

SEGMENT^INDEX 

This field must be. non-zero and specifies an index relative to 
the SEGDEF records found previous- to the LIDATA RECORD. The SEGDEF 
record may specify that the^ data is absolute as one of the 
attributes of the LSEG.- In this case a Frame Number is provided in 
the SEGDEF record.- ttie LIDATA RECORD is reauired to allow qroupinq 
of relocatable LSEG's wi th. absolute LSEG's. 

I TE R AT E D_ DAT A_^^ F FS E T 

This field specifies 'an offset that is relative to the base of 
the LSEG that is specified by the SEGMENT INDEX and defines the 
relative location of the first byte in the ITERATED DATA BLOCK. 
Successive data bytes in the ITERATED DATA BLOCK occupy successively^ 
higher locations of memory. If the SEGMENT INDEX specified an 
absolute LSEG . then the offset is relative to the Frame Number 
provided in the corresponding SEGDEF RECORD. 

ITERATED DATA BLOCK 
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Same as for the RIDATA records 
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FIXUP RECORD 
(FlkUPP) 

is is *' is -k 

* REC ^ RECORD * THREAD * CHK * 

* TYP * LENGTH * or * SUM ^ 

a 9CH ^ ^ FIXUP * * 

± a * * * 

'k^'kisisikis'k'k^^fs^is'kis'k*'k'k'kis'k///'k'k'k-kisisis^isis'k 

I I 

This record specifies or more fixups« Each fixup requests a 
modification (fixup) to a LOCATION within a previous DATA records 

Each fixup is specified by a FIXUP field that specifies 4 data; a 
location^ a mode^ a target and a frame^ The frame and the target 
may be specified totally within the FIXUP fields or may be specified 
by reference to a preceding THREAD field. 

A THREAD field Specifies a default target or frame that may 
subsequently be referred to in identifying a target or a frame^ 
Eight threads are provided; four; for frame specification and four 
for target specification^ Once k target or frame has been specified 
by a THREAD, it may be referred to by following FIXUP fields (in the 
same or following FIXUPP records) ^ until another THREAD field with 
thc: same type (TARGET or FRAME) and thread number (0 - 3) appears 
(in the same or another FIXUPP record) ^ 

THREAD 

THREAD is a field with the following formats 

* TRD ^ INDEX or * 

* DAT * FRAME ^ 

■k- -k M UMBER ^ 

-k -k k ■ 

■kk'kis'k'kk^^'kk / / / k^k-kk 

I I 

4-condi tional-h 

The TRD DAT (ThReaD DATa) subfield is a byte with this internal 

structure % 

kkkkiskkk'kisk:kkk*'kis-kkis-k-kkk*kkiskk'kk± 

* I I I I I I I * 

* I D I Z I METHOD | THRED * 

* I I ! I I I I * 
********************************* 
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The 'Z^ is a one bit subfield^ currently without any defined 
functionjr that is required to contain 0« 

The ^D' subfield is one bit that specifies what type of thread 
is being specified* If D=0 then a target thread is being defined 
and if D=l then a frame thread is being defined. 

METHOD is a 3 bit subfield containing a number between and 3 
(D=0) or a number between and 5 (D=l) « 

If D=0, then METHOD, = (0, 1, 2. 3, 4. 5, 6, 7) mod 4, where the 
0, ,.., 7 indicate methods T0 , ..«, T7 of specifying a target. 
ThuSr METHOD indicates what kind of Index or Frame Number is 
required to specify the target^ without indicating if the target 
will be specified in a primary or secondary way. 

If D=l, then METHOD = 0, 1, 2. 3, 4, 5. 6 corresponding to 
methods F0 , .»., F6 of specifying a frame« Here, METHOD indicates 
what kind (if any) of Index or Frame Number is required to specify 
the frame^ 

THRED is a number between and 3^ and associates a ''thread 
number" to the frame or target defined by the THREAD field. 

INDEX or FRAME NUMBER contains a Segment Index j, Group Index r 
External Index ^ or Frame Number depending on the specification in 
the METHOD subfield. This subfield will not be present if F4 or F5 
or F6 are specified by METHOD. 

FIXUP 

FIXUP is a field with the following formats 

* ^ -k ^ * * 
^ LOCAT ^ FIX * FRAME ^ TARGET * TARGET ^ 

* # D^'Y * DATUM ^ DATUM ^ DIS«» * 

* # # * * PLACEMENT ^ 

^ * * * ^ * 

I I I I 

-fcondi tional+cond itional-i-cond itional + 
LOCAT is a byte pair with the following formats 

^ I I I I I I I * I I I I I I I ^ 

^ 1 I iv| I s I LOC I D A T^A RECORD OFFSET ^ 

I I I I I I I ^ I I I f I I I ^ 

I I I 

+ lo byte + hi byte + 
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M is a one bit subfield that specifies the mode of the fixupsi 
self^relative (M-0) or segment relative (M=l) ^ 

(Note) Self-relative fixups may NOT be applied to 
RIDATA, LIDATA, or PIDATA records. (End of Note) 

S is a one bit subfield that specifies that the lenqth of the 
TARGET DISPLACEMENT subfield. if present, (see below), in this FIXUP 
field will be either two bytes (containing a 16-bit non-negative 
number r S=0) or three bytes (containing a signed 24-bit number in 
2's complement form^ S=l) ^ 

(Note) 3-byte subfields are a possible future 
extension^ and are not currently supported. Thus^ S=0 
is currently mandatory* (End of Note) 

LOG is a 3 bit subfield indicating that the byte(s) in the 
preceding DATA Record to be fixed up are a 'lobyte' (LOC=0) , an 
'offset' (L0C=1) , a ^base* (L0C=2) , a 'pointer' (L0C=3) , or a 
•hibyte* (L0C=4). (Other values in LOG are invalid.) 

The DATA REGORD OFFSET is a number between and 1023 ^ 
inclusive, that gives the relative position of the lowest order byte 
of LOCATION (the actual bytes beinq fixed up) within the preceding 
DATA record. The DATA REGORD OFFSET is relative to the first byte 
in the data fields in the DATA REGORDs. 

(Cautionary Note) If the preceding DATA record is an IDATA 
record, it is possible for the value of DATA REGORD OFFSET to 
designate a ^'location" within a REPEAT COUNT subfield or a BLOCK 
COUNT subfield of the ITERATED DATA field. Such a reference is 
deemed an error. LINK-86*s and LOCATE-86's action on such a 
malformed record is undefined, and probably awkward. (end of 
Cautionary Note) 

FIX DAT is a byte with the following format: 

********************************* 

* I I I I I I I * 

* F I FRAME I T I P I TARGT * 

* I I I I I I I * 

***************************** * * * * 

F is a one bit subfield that specifies whether the frame for 

this FIXUP is specified by a thread (F=l) or explicitly (F=0) . 

FRAME is a number interpreted in one of two ways as indicated 
by the F bit. If F is zero then FRAME is a number between and 6 
and corresponds to methods F0 , ...r F6 of specifying a FRAME. If 
F=l then FRAME is a thread number (0-3). It specifies the frame 
most recently defined by a THREAD field that defined a frame thread 
with the same thread number. (Note that the THREAD field may appear 
in the same, or in an earlier FIXUPP record.) 
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T is a one bit subfield that specifies whether the target 
specified for this fixup is defined by reference to a thread (T=l) , 
or is Given explicitly in the fIXUP field (T=0) . 

P is a one bit subfield that indicates whether the target is 
specified in a primary way (requires a TARGET DISPLACEMENT, P=0) or 
specified in a secondary way (requires no TARGET DISPLACEMENT, P=l) . 
Since a target thread does not have a primary/secondary attribute^ 
the P bit is the only field that specifies the primary/secondary 
attribute of the target specification. 

TARGT is interpreted as a two bit subfield. When T=0 ^ it 
provides a number between and 3, corresponding to methods T0, ..., 
T3 or T4, .... T7, depending on the value of P (P can be interpreted 
as the high order bit of T0 , .... T7) . When the target is specified 
by a thread (T=l) then TARGT specifies a thread number (0-3) . 



FRAME DATUM is the "referent" portion of a frame specification, 
and is a Segment Index, a Group Index, an External Index, or a Frame 
Number. The FRAME DATUM subfield is present only when the frame is 
specified neither by a thread (F=0) nor explicitly by methods F4 or 
F5 or Ff. 

TARGET DATUM is the *• referent" portion of a target 
specification, and is a Segment Index, a Group Index. an External 
Index or a Frame Number. The TARGET DATUM subfield is present only 
when the target is not specified by a thread (T=0-) . 

TARGET DISPLACEMENT is the 2- or 3-byte displacement required 
by "primary" ways of specifying TARGETS. This 2- or 3-byte subfield 
is present iff P=0 • 
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OVERLAY DEFI NITION RECORD 
(OVLDEFT 

* * * * * * * 

* REC * RECORD * OVERLAY * OVERLAY * OVERLAY * CHK * 

* TYP * LENGTH * NAME * LOCATION * ATTR * SUM * 

* 76H * * * * * * 

* * * * * * * 

This Record provides the overlay name^ the location of the 
overlay in the object file, and the attributes of the overlay^ A 
loader may use this record to locate the data records of the overlay 
in the object file^ 

OVERLAY, NAME 

The OVERLAY NAME field provides a name by which a collection of 
1 or more LSEG's and/or Groups may be referenced for loadinq. 

The ordering of OVLDEF Record-s within a module induces an 
ordering on the set of all Overlays defined in the module. Thus, 
OVLDEF records are considered to be numbered: 1, 2^ 3^ 4^ ... 
These numbers are used as "Overlay Indices^' in the OVERLAY ATTR 
field of following OVLDEF records^ 

Overlay indices may not be forward referring^ That is to say, 
an overlay definition record defining the k^th overlay must precede 
any record referring to that overlay with index k^ 

OVER_LA_^ LOCATION 

The OVERLAY LOCATION is a 4-byte field which aives the location 
in bytes relative to the start of the file of the first byte of the 
records in the overlay^ 

OVERLA,Y^_ATTR 

The OVERLAY ATTR field has the followina format: 

* * * * 

* * SHARED * ADJACENT * 

* SA * OVERLAY * OVERLAY * 

* * INDEX * INDEX * 

* * * * 

I I I 

+conditional+conditional+ 
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The SA subfield provides information for memory layout. It has 
the following formats 

****************^^* ************** 

* I I I I I I I * 

*Z|Z|Z|Z|Z|ZIS|A* 
* I I I I I I I * 

* *'* ****************************** 

Z's indicates that these 1-bit field have not been assigned a 
function^ These bits are required to be zero. 

S (shared) is a 1-bit field that, if Ir indicates that the 
overlay will have to be loaded at the same location as the overlay 
indicated in the SHARED OVERLAY INDEX field. 

A (adjacent) is a 1-bit field that, if 1, indicates that the 
overlay will have to be loaded next in memory to the overlay 
indicated in the ADJACENT OVERLAY INDEX field o 

The SHARED OVERLAY INDEX subfield, present if bit S in the SA 
subfield is 1, points to a previously defined OVLDEF record and 
indicates that the segments v^ith same segment names and class names 
and/or the groups with same names in the two overlays must be loaded 
at the same location. 

The ADJACENT OVERLAY INDEX subfield, present if bit A in the SA 
subfield is 1, points to a previously defined OVLDEF record and 
indicates that the segments and/or groups in the overlay defined by 
the current OVLDEF record must be loaded adjacent to the ones with 
the same names in the indicated overlay. 
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END RECORD 
(EMDREC) 

is ^ ± -k -k 

* REG ^ RECORD * END * GHK ^ 

* TYP * LENGTH ^ TYP ^ SUM ^ 
k 78H ^ * ^ Hr 

* ^ * -k ^ 



This . record is used to denote the end of a set of records such 
as a blockp and an overlay^ 

END-- TYP 

This field specifies the type of the set. It has the followinq 

format : 

* I I I I I I I * 

*Z|Z!Z|Z|Z|Z| TYP * 

* I I I I I I I * 

***^*** *********-* **********±****^ 

TYP is a two bit subfield that specifies the followinq types of 
ends; 



T Y P ^ T Y P E ^OF ^EN D . 

■0 "" End" ^o f "oVe f 1 a y 

1 End of block 

2 (Illegal) 

3 (Illeqal) 

Z indicates that this bit has not currently been assianed a 

function^ These bits are required to be zero« 
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REGISTER INITIALIZATION RECORD 
«., fREGINff 

* REG * RECORD ^ REG * REGISTER ^ CHK * 

* TYP ^ LENGTH ^ TYP ^ CONTENTS ^ SUM ^ 

^ 70H ^ ^ * * # 

'k'k^'k'k*±'k*ig'kis±*±'k'k^**'k'k'k'k-k'k'k*'k///'ki€ii-k'k'k'k^^'k'k 



4. -repeated — -f 

This record provides information about the 8086 
registers/register^pairsi CS and IP, SS and SP, DS , and ES. The 
purpose of this information is for a loader to set the neccessary 
registers for initiation of execution^ 

REG^TYP 

The REG TYP field provides the reqister/reqister--pair name. It 
also indicates the type of register content specification given in 
the next field. It has the following format: 

*******^***±***************^***** 

* 1 I I I I I I ^ 

* REGID |Z|Z|Z|Z|Z|L* 

* I I I I I I I * 

Z's are l-bit subfields which indicate that these bits have not 
currently been assigned a function. These bits are required to be 

zeros 

REGID is a two bit subfield that specifies the name of the 
registers/reqister-pairs as follows: 

REGID REGISTER/REGISTER-PAIR 






CS 


and IP 


1 


SS 


and SP 


2 


DS 




3 


ES 





L is a one bit field that indicates whether the REGISTER 
CONTENTS field is to be interpreted as a loaical address (L=l) that 
reauires fixing up by LINK-B6/LOCATE=-36 , or as a pair of base and 
offset specifications (L^Q) appropriate for the initialization of 
the corresponding register/reqister--pair • 
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REGISTER CONTENTS 

The REGISTER CONTENTS field has either of the following 
formats ; 

First form (L=l) 

*** ********/yy*********/y^y*** ******* ******* 

* * * * * 

* REG * FRAME * TARGET * TARGET * 

* DAT * DATUM * DATUM * DIS- * 

* * , * * PLACEMENT * 

* * * ■; * 

***********///*********///***************** 

I I I I 

+conditional+cond itional+conditional + 

In this case the register contents are specified in exactly the 
same manner as in the specification of the mapping of a logical 
address to a physical address as used in the discussion of fixups 
and the FIXUPP record. The above subfields of the REGISTER CONTENTS 
field have the same semantics as the FIX DAT, FRAME DATUM, TARGET 
DATUM, and TARGET DISPLACEMENT fields in the FIXUPP record. Frame 
method F4 is not allowed ^ 

LINK-86/LOCATE-86 will convert the above REGISTER CONTENTS 
field into a field having the following format: 

*****///*** ************** 

* * * 

* REGISTER * REGISTER * 

* BASE * OFFSET * 

* * * 

* * * 
*****///***************** 

I I 

^condi tional4- 

The REGISTER BASE field has. the followina format: 



***** //y^** ****** *//y^ ****** *********** 

* * * * 

* GROUP * SEGMENT * FRAME * 

* INDEX * INDEX * NUMBER * 

* * * * 

* * * * 

***** //y^*** ****** ///***************** 

I I 

+condi tional+ 
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The format and the interpretation of the above REGISTER BASE 
field is identical to the LOCAL SYMBOL BASE described in the LOCSYM 

records 

The REGISTER OFFSET field (present only if REGID <= 1) 
specifies an offset relative to the Segment (if SEGMENT INDEX > 0) 
or to the FRAME (if SEGMENT INDEX = 0). 

(Note) Once the segments and/or groups are 
absolutely located (by a loader or LOCATE-86) , the 
base of the object , pointed to by the REGISTER BASE 
field is the appropriate value for the initialization 
of the corresponding base register. The offset value 
for the initialization of either the IP register 
(REGID = 0) or the SP register (REGID = 1) is 
determined as follows: 

If GROUP INDEX = 0, the offset value is given by 
the value specified in the REGISTER OFFSET field. 

If GROUP INDEX > 0r the offset value is the 
offset relative to the base of the specified qroup of 
the location specified by the pair (SEGMENT INDEX, 
REGISTER OFFSET) . (End of Note) 
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MO DULE END RECORD 
(MODEND) 

* -k is -k * ir 

* REC * RECORD ^ MOD ^ START * CHK ^ 

* TYP * LENGTH ^ TYP ^ ADDRS * SUM * 

-k 8AH ^ * * * * 

* ^ ^ # * * 

* * * ^ * * ir ^ir * ^ ^ * * * * 1^ * Jr * 1^ * * ^ * * lir * ^/// ^ * * * ^ * ^ * • * * 

I ! 

-i-conditional + 

This record serves two purposes^ It denotes the end of a 

module and indicates whether the module just terminated has a 

specified entry point for initiation of execution^ If the latter is 
true then the execution address is specified ^ 

MOp^TYP 

This field specifies the attributes of the module. The bit 
allocation and associated meanings are as follows: 

* I I I I I I I * 

* MATTR |Z|Z|Z|Z|Z|L* 

* I I ! I I I I * 

********************************* 

MATTR is a two bit subfield that specifies the followinq module 

attribute's; 



MATTR i^QDULE^AjTTR^UTE 

■ Non-main module" with no START ADDRS 

1 Non-main module with START ADDRS 

2 Main module with no START ADDRS 

3 Main module with START ADDRS 

L indicates whether the START ADDRS field is to b# interpreted 
as a logical address that reouires fixinq up by LINK-86/LOCATE-3f^ 
(L=l) or as a physical address appropriate for placement into the CS 
and IP registers of the 8085 (L=0) . 

Z indicates that this bit has not currently been assiqned a 

function. These bits are required to be zero^ 
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The START ADDRS field (present only if MATTR is 1 or 3) has 
either of the following formats i 

START ApDR^_ j firs t_ form) 

Jr * ^ -^ * 

^ END * FRAME ^ TARGET * TARGET * 

* DAT ^ DATUM * DATUM * DIS- * 

* ^ * ^ PLACEMENT * 

* * -k -k * 

I I I . . I 

+conditional+cond itional+conditional-f 

The starting address of a module has all the attributes of any 
other logical reference found in a module. The mapping of^a logical 
starting address to a physical starting address is done in exactly 
the same manner as mapping any other logical address to a physical 
address as specified in the discussion of fixups and the FIXUPP 
record. The above subfields of the START ADDRS field have the same 
semantics as the FIX DAT, FRAME DATUM, TARGET DATUM, and TARGET 
DISPLACEMENT fields in the FIXUPP record. Only '^primary" fixups are 
allowed. Frame method F4 is not allowed. 

START ADDRS (second form) 

When the logical address is mapped^ by L0CATE-8f^, to a physical 
address, the START ADDRS field takes on the following formats 

^ # * 

* FRAME ^ OFFSET * 

* NUMBER * * 

* -k * 
^ -k * 



FRAME NUMBER specifies a frame number relative to which the 
module will begin execution. This value is ^appropriate for 
insertion into the CS register for program initiation. 

OFFSET specifies an offset relative to the FRAME MUMBER which 
defines the exact location of the first byte at which to begin 
execution. This value is appropriate for insertion into the IP 
reqister for program initiation* 



81 



8086 Object Module Forinats Version 4^0 



LIBRARY HEADER RECORD 
""""fCIBHED) 

* * * * ± * ^ 

* REC * RECORD * MODULE * BLOCK * BYTE * CHK * 

* TYP * LENGTH * COUNT * NUMBER * NUMBER * SUM * 

* A4H * * * * * * 

-k -k * * is * * 



This record is the first record in a library file^ It 
immediately precedes the modules (if any) in the library^ Following 
the modules are three more records in the followina order: LIBRARY 
MODULE NAMES RECORD, LIBRARY MODULE LOCATIONS RECORD, and LIBRARY 
DICTIONARY RECORD. 

MODULE C OUNT 

This field indicates how many modules are in the library^ It 
may have any value^ including zero^ 

BLOCK N UMBE R^. BYTE NUMBER 

These fields indicate the relative location of the first byte 
of the LIBRARY MODULE NAMES RECORD in the library file^ using the 
ISIS--II file format. 
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LIBRARY. MODULE: NAMES RECORD 

(LIBNAM) 

***^***^ifc** ************///*** ******** 

* * * * * 

* REC * RECORD * MODULE * CHK * 

* TYP * LENGTH * NAME * SUM * 

* A6H * * * * 

* * * • * 

******•****************///*********** 

I ! 

4— repeated— + 

This record gives the names of all the modules in the library. 
The names are qiven in the same sequence as the modules appear in 
the library^ 

MQDjJLE.^ NAME 

The i'th MODULE NAME field in the record contains the module 
name of the i ' th module in the library^ 
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LIB RARY MODULE LOCATION S RECORD 
(LIBLOC) 

•k-k -k * -k -k -k 'k * -k -k -k ^ * -k -k -k -k' * * *-*■ * ii -k -k *■* k k k * kkk k *■* ** kkkkkkkk* 
k * k * k * 

* REC * RECORD * BLOCK * BYTE * CHK * 

* TYP ^ LENGTH * NUMBER * NUMBER * SUM * 

*. p^QH k * *■ * * 

-k k * * * * 

^-M-kkkkkkkkkkkkkkkkkkkkkkk-kk-kkkkkk-kkkkk-kkkkkkkkkk* 



-reoeated- 



This record provides the relative location^ within the library 
file, of ■ the first byte of the first record ( either a. THEADR or 
LHEADR or RHEADR record) of each module in the library. 

The order of the block-number/byte-number pairs corresponds to 
the order of the modules within the library. 

BLOCK ^ NUMBER ^ B YTE PJUMBER 

The i ' th pair of fields provides the relative location within 
the library file of the first byte of the first record of the i ' th 
module within the libraryr usinq the ISIS-II file format. 
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LIBRAR Y DICTI ONARY RECORD 
(LIBDIC) 

^-* ±^****ik-**^**^ ****** *i^///^^W!^±**^^^^i^^^^** 
± * * * * * 

* REG * RECORD * PUBLIC * * CHK * 

* TYP * LENGTH * NAME ^ 00H ^ SUH * 

* AAH * ^ * * * 

^ * * * * * 

***********************///*** **^*^^*^^***** 

I I I 

+_j^epeated — + | 
4— repeated- -+ 



This record gives all the names of public symbols within the 
library^ Since a name must have a non-zero lenqth, the '00' bytes 
in the format are distinguishable from the PUBLIC MAME fields. 
Thus, the '00* bytes separate the PUBLIC NAMES into groups? all 
names in the i • th group are defined in the i ' th module of the 
library. 
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COMMENT _R ECORD 
(COMENT) 

* * * * * * 

* REC * RECORD * COMMENT * * CHK * 

* TYP * LENGTH * TYPE * COMMENT * SUM * 

* 88H * * * * * 

* * * * * * 
***********************************///*********** 



This record allows translators to include commentary 
information in object text^ 

COM MENT TYPE 

This field indicates the type of comment carried by this 
records This allows commentary information to be structured for 
those processes that wish to selectively act on comments^ The 
format of this field is as follows: 



***^±******^****************^****5%*^****************************** 
^ N I N I I I I I I * COMMENT * 

*P!L|Z|Z|Z!Z|Z|Z^ CLASS ^ 

** ^' ******^*** ************* ■^-*^^****-^*^*'*****^*********"^*^******^*** 

The NP (NOPURGE) bit. if 1. indicates that the COMENT record is 
not purqable by object file utility proqrams which implement the 
capability of deleting COMENT record. 

The NL (NOLIST) bit, if 1, indicates that the text in the 
COMMENT field is not to be listed in the listing file of object file 
utility proqrams which implement the capabiltiy of listinq object 
COMENT records. 

The COMMENT CLASS field is defined as' follows: 



Lanquaqe translator comment 

^ Intel copyright comments The NP bit must be 
set .' 

2-155 Reserved for Intel use. 

156-255 Reserved for users^ Intel products will 
apply no semantics to these values^ 
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COMMENT 

This field provides the commentary information, 



Pj 
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APPENDIX 1 



NUMERIC LIST OF RECORD TYPES 



m RHEADR 
70 REGINT 
72 REDATA 
74 RIDATA 
76 OVLDEF 
78 ENDREC 
7 A BLKDEF 
7C BLKEND 
7E DEBSYM 
80 THEADR 
82 LHEADR 
84 PEDATA 
86 PIDATA 
88 COMENT 
8A MODEND 
8C EXTDEF 
8E TYPDEF 
90 PUBDEF 
92 LOCSYM 
94 LINNUf^ 
96 LNAMES 
98 SEGDEF 
9 A GRPDEF 
9C FIXUPP 
9E (none) 
A0 LEDATA 
A2 LIDATA 
A4 LIBHED 
A6 LIBNAM 
AS LI BLOC 
AA LIBDIC 
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APPENDIX 2 

TYPE REPRESENTATIONS 

The leaves in the following diagrams may be Numeric Leaves 
without relations. String Leaves, Index Leaves or Null Leayes. 
Andleaves and Orleaves are not supported at this time. 

Types may be defined by branches of the following forms: 

I I I 

I SCALAR i (length) I (scalar type) ! 

^. ., ^^^, . +^^„-.-. . + 



+-»• + 

I POINTER I 

+ + 



^^^ .-.+ — . . + — ~ -f 

I SCALAR I (length) I ^pointer I 

^ ,^^+ . + + 

I I I 

II I I 

^. + + ^^ +~^ -| 

I STRUCTURE | (length) I (number of components) I ^list of components 1 

^^. ^ + . ^^-.„^-. ^^-. + ■ ^ 



I LIST |?|?l?l «..!?! 

^ 4..^ +-. 4.. 4- 4- + 



+„^.«^.4. ^ ^+ + 

I ARRAY I (lenqth) I Ptype I 
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4. 4. . — ^ 

I PARAMETER | @type | 

4. ,^^ « — 4. 

I I 

till II 

^ . 4, ^^^. ^ . --._+ . _^_ , — . . 4»_ .-^.4. 

I PROCEDURE I nil | (atype | (return) I (number of parameters) I faiist I 

4. 4. 4 + . . 4, . . . -+ 4. 

III! II 

I I ! 

4 4. _4. « .4 

I LABEL I nil | (return) I 

+ . — + .^4 _«„, 4 

I I I 



where 
INTEGER, or 
indicates ^ 
should be a 



"(scalar type) ^ can be either UNSIGNED INTEGER, SIGNED 
REAL, *'( return)^' can be either SHORT or LONG (which 
in the case of a LABEL^ whether a jump to the l.ibel 
"short" jump or a "lonq'' jump^ respectively), and the 



followina values are assianed: 



99 


INTERRUPT 


100 


FILE 


101 


PACKED 


102 


UNPACKED 


103 


SET 


104 


(reserved 


105 


CHAMELEON 


106 


BOOLEAN 


107 


TRUE 


108 


FALSE 


109 


CHAR 


110 


INTEGER 


111 


CONST 



for length) 



112 (reserved for lenath) 

113 LABEL 

114 LONG 

115 SHORT 

116 PROCEDURE 

117 PARAMETER 

118 DIMENSION 

119 ARRAY 

120 (reserved for lenath) 

121 STRUCTURE 

122 POINTER 

123 SCALAR 

124 UNSIGNED INTEGER 

125 SIGNED INTEGER 

126 REAL 

127 LIST 



(Note) 1. The above (dec 
for the convenience of ut 
EDOJ86, and 0JED86. All 
(although conceptually ther 
and SCALAR^ for example^ can* 
and are rather ^large / so th 
programs may correctly decide 
Numeric Leaf as a number o 
th-is choice correctly most of 
give a wronq identifier^ 
2. For more detailed type 
translator EPS's (e.g. AS 
FORTRAN-86) . (end of Note) 



iraal) values are chosen 
ility programs such as 
numbers are different 
e is no reason why REAL 
t be the same number) p 
at object module display 
whether to represent a 
r as an identifier, make 
the time^ and never 

descriptions see the 
M-86, PLM-86, PASCAL-8^, 
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APPENDIX 3 



SYNTAX DIAGRAMS 



object^f ile 

4. , .^4. 

• — +— ->! sequence | 
I + •• "+ 

I 

I 4 ^ + 

|-'-^>| library I 

4—^ + 



sequence 

4. — _ ^ 

__+ — >| module I — -i- — > 
+ + I 

4« . .... 4. 



library 



-- >( LI8HSD )~+ — •+ — X LIBNAM ) ~> ( LIBLOC ) — >( LIBDIC ) — > 

4. — I module |< — + 

4 — ,, 4. 

module 

_.+-.- > j t mo d I ~+— . > 

j +„..^^4» - 
j ■ 4™.«^^4» I 

+"> ! Imod ! — -+ 

^ 4„>[ rmod f ~+ 

I +~— + I 
+«->j omod I -— + 
+ ■ — — + 
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tmod 



. + ^ 

— >( THSADR )->| sqr table | -+- 



-+-— + 



. ^^y\ mod tail I — > 

-- + — , — + I 4» , 4. 

■f -* I component | <--f 

+ . 4. 



Imod 

^„ + ^^. ^ + ^^^"^ + 

~>{ LHEADR )->| sqr table | — f -.4«-.4 . ,-. +-> | modtail I — ) 

4— «.«Z^^-.-. — + - ^^^ + I -^ +^-— „,„-.-4. I 4-^ — ^^^ + 

+-I data |<-+ +- I t_component I <--+ 

rmod 

^ +_^.^ -.-,-4. 4 -f 

— >( RHEADR )->! sqr table | -»+ + — +-•• — — .„4«-> | modtail |~> 

^^^^^. +_.«-J«.^ .4 - 4..^ ,4 I " +- ' -.^—4 I 4 —4 

4-1 data |<-4 4- It component I <-+ 

4~« -4 -f--- — + 



omod 



4 — ^- — ,^^^. 4. 

~> ( RHEADR )->! sqor table |- 



.^.__ -„..^ — « — .-. — 4«> I o modtail I — -> 

4- I o component I <-+ 
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sqr table 

^ ^ 

— >| seq qrp I — + ^ + — > 

+ -^ + I 

+ — X REGINT ) — + 



sgor ^table 

+ . — . -4- 

^-> I seq qrp I — +-- ^ ' + — + ^ > 

+„.«-^ + - -.^. I I '^ 

4" — { OVLDEF )< — + + — X REGINT ) — + 



seq ^grp 

— ^»• — . . 4- — + +-- -+ + — > 

'^ „ I - I - I 

+•—( LNAMES )<— f +~{ SEGDEF ) <^^-l» +~ ( TYPDEF )<^-+ 



+--( EXTDEF X — + 
+„( GRPDEF ) < — + 



modtail 



.+ .-. — + — >( MODEND ) — > 

I ^^-.- - -— 

^ — >( REGIMT ) — + 



o modtail 



.+«_ ., . -^+„+ ^ . + — >( MODEND )— > 

^„^.„. I I — - 

+--{ OVLDEF )< — + -¥ — X REGINT ) — + 
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o component 



.+. ^ . — -+^^4. — •«--. •• — ^ + — >( ENDREC ) — > 

- + + I - +™ .+ I 

+ — I data |< — + +~| t^^component |<~+ 



t component 



— >( THEADR ) — + ^- — ~ ■— - — + — > 

+ — I component |< — + 



component 

+ ^^^ . + 

— -f- — >| ^ data I— .+— > 

I +„..^^ ^.^.+ - 

I + ^.^„^.„-+ I 

+ — ,> I debug ^record | — + 

4.. — ., — ^: — ,^, — ,-.«+ 
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data 

+ + 

— + — >| content_def I + — > 

I + + - 

I + _ ^. I 

+ — >| thread def | — ->+ 

I + Z + I 

I I 

+ >( TYPDEF ) > + 

I I 

I I 

+ >( PUBDEF ) > + 

I I 

I I 

+ >( EXTDEF ) >+ 

debuqrecord 

— + — >( LOCSYM ) + — > 



+ — >( Llf^^NUM ) -->+ 

I I 

1 I 

+ — > ( BLKDEF ) — >+ 

I I 

I I 

+ — X BLKEND ) — >+ 



+ — >( DEBSYM ) — >+ 



95 



80*8^ Object Module Formats Version 4, 



content def 



— +^-.>( LIDATA ) + — + •„^+ — > 



.^ I +-,^( FIXUP? )< — + 

+-^>( LEDATA )~>-l- 



4. — >( piDATA ) — >+ 



^ — X PEDATA ) — >+ 



„, I 

+ — >( RIDATA ) — >+ 



+ — >( REDATA ) — >+ 



thread _def 

>( FIXUPP ) — > Motei Must contain thread fields only. 
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APPENDIX 4 



EXAMPLES OF FIXUPS 



This appendix was originally written in Movember 1977, and 
supplemented a paper, now obsolete, called ^'Overview of Proposed 8086 
Fix.ups^'o It is included here because it provides copious examples of 
fixups in pictorial represea^featioa , and therefore is an aid to 
understanding the 8086 fixup inechanisms o 

In the followinq examples, we assume that LINK is the name of a 
linker and LOCATE is the narae of a locater for the 8086 R&L system. 

Examples of Sel f--relative fixups appear in PART 1 of this appendix? 
examples of Seqiiient-=relative fixups appear in PART 2o 



KEY TO SAMPLE FIXUP DIAGRAMS 

The diaqrams are coded as follows: 

PPP .•. indicates the boundary of a PSEG 
LLL .•• indicates the boundary of an LSEG 
i^MM .«. indicates real memory boundaries 
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PART 1« SELF-RELATIVE REFERENCES 



<- PP 



<-- PT 



I LOCATION 



PPPPPPPPPPPPPPPPPPPPPP <=^= PSEG --> PPPPPPPPPP 

P P . P 

P P 

P P 

P P 

p +«_„„«___««— _^ p 

P ! TARGET I P 

p ^««_«-.««__««.«»4. p 

p - p 

P I P 

P I P 

P I P 

p ! P 

p 4._=^__«,«««_«««_^ p 

P ! LOCATIOM ! P 

p j^^^^^^^^^^^^^^.^^ p 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 

P P 



P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 



PPPPPPPPPPP 



TARGET 



P 
P 
p 
P 
P 
p 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
p- 



<» PP 



<=- PT 



PPPPPPPPPPPPPPPPPPPPPP 



ppppppppppi PPPPPPPPPPP 

I 



PP •-- point defininq 
PT - point defining 



PSEG, .usually an LSEG 
the TARGET 



If the positions of LOCATION and TARGET 
diagrams^ then the arrows would point down instead 



distance between the top of the 
and is commonly zeroo 



?n 



and point PP is less tn 



^AFere exchanqed in the 
of upo Notes The 
16 bytes ^ 
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1.1 Self-Relative Intraseqment References 



LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 



L 








L 


L 








L 


L 
L 
L 
L 
L 


-JL— 




— 9--,-l, 


L 
L 
L 
L 
L 


1 


TARGET 


• — "T 

1 


t"^ 


- 


"•■"T 


L 








L 


L 








L 


L 








L 


L 








L 


L 








L 


L 
L 

L 
L 
L 








L 

L 
L 
L 
L 


1 


LOCATION 


1 




1 




L 




1 




L 


L 




1 




L 


L 




1 




L 


L 
L 
L 


_i-.^ 


V 


«»«<»«1. 


L 
L 
L 


1 


TARGET 


1 


L 

L 


-L,«. 




,«»--, 4, 


L 
L 


T"^ 




"•■•t^ 


L 








L 


L 








L 


L 








L 


L 








L 


L 








L 


L 








L 



LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 



Self-Relative references within a sinqle LSEG do not require 
fixiip, the translator puts the appropriate value into LOCATIOM. 
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1.2 Self-Relative Intersegment References 

Examples Self--relative jump or call to another segment. 



A LLLLLLLLLLLLLL 
L L 

L I LOG 1-^— 

L L 

L L 

L L 

LLLLLLLLLLLLLL 



<- PP 



B LLLLLLLLLLLLLL 
L L 

L L 

L L 

L ^^^^^^-^^^^ L 

.^^=^> j TARGET I L 

L L 

LLLLLLLLLLLLLL 



dl 
! 
V . <- PT 



Both LSEG°s are created in the same translation. 



FIXUP. REPRESEMTATION: 



LOCATIONS OFFSET or LOBYTE 

PSEGs SI (A) (this is the most common choice) 

TARGETS SI(B) ,dl 

or SI(B) (see diagram and discussion followinq LOCATE OPERATIC 

LINK. OPERAT I ON: 

If LSEG B combines then the LINKER will modify all fixups of the 
above form by chanqing SI(B),dl to SI(B),dl4»d2 



D ooo©o®e©ciooi>oo 

= ! 

B LLLLLLLLLLLLLL " 
L L dl 

L +„„„_=.__=.+ L V 

L i TARGET I L 
L +„„„^-„„=.+ L 

L L 

L L 

L L 

LLLLLLLLLLLLLL 



L L 

L +=»_ — _ — + L <- PT 

L I TARGET | L 

L 4— — -+ L 

L L 

L L 

L L 

L L 

LLLLLLLLLLLLLL 
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LOCATE OPERATION: 



At LOC^fiiTE time these various sample possibilities can be detected 



PPPPPPPPPPPPPPPPPP 



PPPPPPPPPPPPPPPPPP 



3. PPPPPPPPPPPPPPPPPP 



p 


P 




P 




P 


P 




P 


P LLLLLLLLLLLLLL 


P 


<■= PP 


p 


LLLLLLLLLLLLLL 


P <- 


» PP P 


LLLLLLLLLLLLLL 


P 


P LA L 


P 




p 


LA L 


P 


P 


LA L 


P 


P L ^.— =— .-+ L 


P 




p 


L 4.„=.» <=»-_»+ L 


P 


P 


L +«,„„„=,^-.-.+ L 


P 


P L 1 LOG 1 L 


P 




p 


L ! LOG I L 


P 


P 


L I LOG 1 L 


P 


p L >«—-==.-==.-!. L 


P 




p 


L +=.=,«»»=.=^+ L 


P 


P 


L +„„„„=.-.=.==-}. L 


P 


PL i L 


P 




p 


L 1 L 


P 


P 


L i L 


P 


P LLLLLLILLLLLLL 


P 




p 


LLLLLLI LLLLLLL 


P 


P 


LLLLLLi LLLLLLL 


P 


P 1 


P 




p 


! 


P 


P 


I 


P 


P LLLLLLILLLLLLL 


P 




p 


1 


P 


P 


! 


P 


P LB V L 


P 




p 


1 


P 


P 


1 


P 


p L +«=.-=^ »-»=.— f L 


P 


<=» PT 


p 


LLLLLLI LLLLLLL 


P 


P 


! 


P 


P L I TARGET , 1 L 


P 




p 


LB V L 


P 


P 


1 


P 


P L ^— =.——!. L 


P 




p 


L +—»—.-—+ L 


P < = 


= PT P 


1 


P 


PL L 


P 




p 


L I TARGET I L 


P 


P 


LLLLLLI LLLLLLL 


P 


P LLLLLLLLLLLLLL 


P 




p 


L ^„-._-.»=-,»+ L 


P 


P 


LB I L 


P 


PPPPPPPPPPPPPPPPPP 




PPL LPP 


PPL V Ll-'F 










LLLLLLLLLLLLLL 






L + . —+ L 

L I TARGET 1 L 








5e 


PPPPPPPPPPPI PPPPPP 




LLLLLLLLLLLLLL 










P 


1 


P 








„ LLLLLLLLLLLLLL 






P 


LLLLLLLLL! LLLL 


P 


<■= PP 






L8 L 






P 


LB V L 


P 








L ^^==,„»=.„„=.+ L 


<=- 


PT 


P 


I +„ »_+ L 


P 


<-. PT 






L i TARGET I L 






P 


L 1 TARGET ! L 


P 








L ^==,«.= «,^»=.-4. L 






o 
fa 


L +- — . -=.+ L 


P 








L ~ L 






P 


L - L 


P 








LLLLLLf LLLLLLL 
1 






P 
P 


LLLLLLILLLLLLL 

1 


P 
P 








1 

pppppppp! ppppppppp 




P 


1 

I 


P 








P LLLLLLILLLLLLL 


P 


<-=■ PP 


P 


LLLLLLILLLLLLL 


P 








P LA I L 


P 




P 


LA 1 L 


P 








p L +=— — + L 


P 




P 


L 4.„„„„„„„»+ L 


P 








P L 1 LOG 1 L 


P 




P 


L 1 LOG 1 L 


P 








p L +-.«=»«=.=.«<>+ L 


P 




P 


L ^..-„„-.-.-,-4- L 


P 








PL L 


P 




P 


L 5 L 


P 








P LLLLLLLLLLLLLL 


P 




P 


LLLLLLLLL! LLLL 


P 








P 


P 




P 


1 


P 








P 


P 




PPPPPPPPPPPVPPPPPP 








P 


P 
















P 


P 
















P 


P 
















P 


P 
















P 


P- 

















<- P' 



PPPPPPPPPPPPPPPPPP 
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Oiagrams 1 and 2 show valid fixups. In diaqram 3^ the TARGET is not 
in the defined PSEG. .A warning will be given by LOCATE. In diaqram 4p 
if the choice for PSEG is changed from SI (A) to SI(B) then the fixup can 
be iiiader as in diagram 5| if the displacement is greater than 32K a 
"clever'' fixup^, shown in diaqram 5 as an exclamatory arrow, will be 
generated « 

R & L attempts to inform the user of any erroneous self-^relative 
references. The symbol being referenced must be within the defined PSEG 
independent of the bias value to be applied: 



EXAMPLES: JMP SYM + 10 



or 



JMP SYM - 2 



The symbol SYM will have an offset within its containing LSEG. The 
values 10 and -2 are biases. If the offset of SYM is added to the bias 
in LOCATION and the result overflows^ it is not known whether this is due 
to the offset of SYM being greater than S4K or whether the bias (perhaps 
a negative or positive number) caused the overflow^ If the bias caused 
the overflow then the reference is good according to R & L^ if not, then 
SYM is not in the defined PSEG and the reference is invalid. 



The solution to this 
independent of the bias. If 
(e.g. , ^'TARGET: SI(B) ,d*^ , 
fixup record itself and will 
If the TARGET is specified 
then the offset must 
less checking on the 



problem is to maintain the offset of SYM 

the TARGET is specified in a primary way 

then the offset will be maintained in the 

be added to LOCATION only at LOCATE time. 

in a secondary way (e.q.^ "TARGETt SI(B)")^ 

be maintained in LOCATION itself^ and R & L can do 

correctness of the fixup. 



If the LOCATION is an OFFSET (i.e., a full word /not just a byte) 
and the bias is known to be zero^ then a fixup target oft TARGET; SI(B) 
could be used instead of TARGETi SI(B),dl, without sacrificing any 
correctness checking ^ 
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1,3 Self-^Relative Reference To An EXTERNAL Symbol 



A LLLLLLLLLLLLLL <- PP 
L L 

L +— — «-^+ L 

L I LOC |^==>^— ^— 

L L 

LLLLLLLLLLLLLL 



a QOOOO0OO 



o o o o o o 



=>. SYM . 



<- PT 



WlKUBs-MEPRESEHThTlMz 



LOCATIONS OFFSET or LOBYTE 

PSEGs SI (A) {this is the most common choice) 

TARGETS ElfSY'M) ,0 

or EI(SYM) if the offset is to be maintained in LOCATION 

Of if the reference is to the i ' th element of an external arrays 



LOCATION? OFFSET or LOBYTE 

PSEGs SI (A) this is the most common choice 

TARGET? ElfSYM) ,i->l 



Llt^K QPERATIOMg 

There are three ways in which an external self-relative reference 
may be resolved o 

CASE Iz The EXTERNAL symbol (SYM) is found (by LIMK) to be in the same 
LSEG as the LOCATION. 

CASS 2s The EXTERMAL symbol (SYM) is found (by LINK) to be in a 
different LSEG, B. 

CASE 3s The EXTERNAL symbol (SYM) is found (by LINK) to be absolute. 
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CASE Is EXTERNAL symbol (SYM) is found (by LINK) to be in the same LSEG 
as the referencGo The following four cases existo 

Assume that PSEG is specified as ^^PSEG: LOCATIOM^' « 



LLL 

L -¥■ 



PPPPP 

P 

P 

P 

P 

P 

P 

? 

p 

P 

P 

P 

P 

P 

P 

P 

P 



L ! 
L +■ 
L 
L 
L 
L 

L ^- 
L ! 
L +' 
L 

LLL 
PPPPP 



PPPPPPPPPPPPP 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 

LLLLLLLLLLL P 
PPPPPPPPPPPPP 



LLLLLLLLLLL 

^^^^^^^^^ L 

LOG ! L 

I L 

I L 

I L 

V L 

^^^^^^^^^ L 

L 
L 
L 



TARGET 



<^ PP 



<- PT 



pppppppppppppppppp 

P P 

P P 

P P 
P LLLLLLLLLLLLLL P 

p L 4'=-'='-^-^-='-=--^^ L P 

P L I TARGET | L P 

p L 4^==.^-«— ===^4- L P 

PL " LP 

PL I LP 

PL I LP 

PL i LP 

p L 4^^-— <=.=f L P 

P L I LOG 1 L P 
p L 4-^^«-— ^^^ L P 
PL LP 

P LLLLLLLLLLLLLL P 
PPPPPPPPPPPPPPPPPP 



<^ PT 



<- PP 



PPPPPPPPPPPPPPPPPP 
! 



P ! P 

P LLLLLLILLLLLLL P 

PL ! LP 

p L ^^^-^^^^^^-^ LP <«- PP 

P L I LOG i L P 

p L +«=»«.«.==.«>«.«^4 L P 

PL LP 

PL LP 

PL LP 

PL LP 

PL LP 

p L +— — — >«>4 LP <- PT 

P L ! TARGET ! L P 

p L 4-——==^+ L P 

PL "^ LP 

P LLLLLLILLLLLLL P 

ppppppppi ppppppppp 



PPPPPPPPI PPPPPPPPP 
! P 

LLLLLLILLLLLLL 
¥ L 



! TARGET ! 



P 

P 

P L 

P L 

P L 

p L ^^^^^^^^ 

P L 

P L 

P L 

P L 

P L 

p L +-=-.«—-.- 

P L I LOG 

p L +-^«.— -=» 

P L ! 

P LLLLLLILLL 

PPPPPPPPVPPP 



L 
L 

^4 L 
L 
L 
L 
L 
L 

^+ L 
! L 

^^ L 

L 
LLLL 



P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 



<« PT 



<- PP 



PPPPPP 



Depending on the absolute lenqth of the arrow, LINK can perform a 
"normal" fixup or a "clever'' fixuo (exclamatory arrovj) « Note that even 
if the LSEG continues to qrow in future LIMKinq, the fixup is OK as lonq 
as the LSEG remains less than 64K in length, which is enforced by LINK« 
Thus the fixup is completely Resolved by LINKo 
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CASE 2% EXTERNAL symbol (SYM) is found to be in a different LSEG^ 
The following diagram then applies and LINK converts the fixup tot 



B. 



LOCATION I (no change) 

PS EG I (no change) 

TARGETi SI(B) ,dl 

or SI(B) where dl is applied to LOCATION depending on 
original TARGET specif ication* 
LINK will specify the new TARGET in a primary 
(secondary) way if the old TARGET was 
specified in a primary (secondary) way^ 



A LLLLLLLLLLLLLL 



L 
L 
L 
L 

L 
L 
L 
L 



LOC 



L 

L 

L 

»-!• L 



L 
L 



LLLLLLLLLLLLLL 



B LLLLLLLLLLLLLL 



L 
L 
L 

L 



L 
L 
L 



SYM 



L 
L 
L 
L 
L 
L 
L 
L 



LLLLLLLLLLLLLL 



! 
dl 



m 



Note 
(1«2) . 



that this fixup is now exactly the same as the fixup specified 
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CASE 3t EXTERNAL symbol (SYM) is found (by LINK) to be absolute. 
LINK will change the fixup to the followinqs 

LOCATIONi same 

PS EG I same 

TARGETj p# (SYM) ,d (SYM) 

where p# and d are from a PUBLIC DECLARATIONS record 
or p#(SYM)^ and d(SYM) is applied to LOCATION^ 

LOCATE OPERATION! 

At LOCATE time^ LOCATE knows the following: 

a) the memory address of LOCATION 

b) the memory address of the PSEG 

c) the memory address of the PUBLIC 

If either the LOCATION or TARGET is not in the PSEGi, LOCATE can 
report a warnings YOU CAN'T GET THERE FROi^ HERE« Otherwise i. a self- 
relative fixup can be completed as shown in (1^2). 
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1.4 (8089) Self-Relative Reference To An EXTERNAL Symbol 

A LLLLLLLLLLLLLL <- PP ? 

L L 

L ^„^-. + L ■ 

L I LOC I — >. SYM . 

L + + L .s « . 

L L 

LLLLLLLLLLLLLL , 



<- PT 



FIXUP REPRESENTATION! 



LOCATION^ OFFSET 

PSEGi SI (A) (this is the most common choice) 

TARGET! EI (SYM) ,d 

or EKSYM) if the offset is in LOCATION 



There are two ways in which an 8089 self-relative reference to an 
external symbol may be resolved^ 

CASE 1j The EXTERNAL symbol (SYM) is found (by LINK) to be in a 

different LSEG, B« 

CASE 2: The EXTERNAL symbol (SYM) is found (by LIMK) to be absolute ^ 



107 



8086 Object Module Formats 



Version 4«0 



CASE I: EXTERNAL symbol (SYiM) is found (by LINK) to be in a different 
LSEG, B. 

LINK OPERATION z 

LINK will change the above fixup to the followinqi 

LOCATIONi (no chanqe) 
PSEGi (no chanqe) 
TARGETS SI (B) ,dl 

where dl is equal to the sum of d (if any) 

and the symbol offset. 



A LLLLLLLLLLLLLL 
L L 

L L 

L L 

L ^^^ -h L 

L I LOG I 

L 4- -f L 

L L 

L L 

LLLLLLLLLLLLLL 



B LLLLLLLLLLLLLL 



L 
L 
L 
L 



TARGET .. 



L 
L 
L 



L 
L 
L 
L 
L 
L 
L 
L 



dl 

I 

V 



LLLLLLLLLLLLLL 



LOCATE OPERATION I 

At LOCATE time various possibilities can be detected; 



1« LLLLLLLLLLLLLL 
LA L 

L + -^^-i- L 

L I LOG I L 

1^ 4. — ^^ + L 

L I L 
LLLLLLILLLLLLL 

I 
LLLLLLI LLLLLLL 
LB V L 
L'-4. 4. L 

L I TARGET | L 

L + — : 4- L 

L L 

LLLLLLLLLLLLLL 



<-» PP 2. LLLLLLLLLLLLLL <- PT 
LB L 

L +- + L 

L I TARGET | L 

L 4- L 

L '^ L 
LLLLLLILLLLLLL 

I 

I 

I 
<-- PT LLLLLLILLLLLLL 
LA I L 

L 4- -f L <- PP 

L I LOG I L 

L 4- ^ — + L 

L L 

LLLLLLLLLLLLLL 
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Diagrams 1 and 2 show two commom cases« 



self-'relative 



R&L attempts to inform the user of any erroneous 
references (TARGET not within 32K from LOG) . The symbol beinq referenced 
must be within the defined LSEG independent of the value at LOGATION to 
be applied! 



EXAMPLES; 



JMP SYM 4- 10 



or 



JMP SYM -- 2 



The symbol SYM will have an offset within its containinq LSEG. The 
values 10 and -2 are signed numbers^ The fixup output by an 8089 
translator may be 

LOCATIONS OFFSET 

FRAMES F6 

TARGETS EXTERNAL (SYM) , DISPLACEMENT = number 

The output of LINK will be s 



LOCATION: 

FRAMES 

TARGETS 



OFFSET 
F6 
SEGMENT (B) 



DISPLACEMENT = number 4- offset 



where 'number 4- offset^ is the sum of the sianed 'number' and the non- 
negative ^offset^ of the symbol from the base of the segment B. Warninq 
will be issued if overflow or underflow occurs during the computation of 
this displacements 

LOCATE will compute the 20-bit address of TARGET and the 20-bit address 
of LOCATION, then the signed displacement from the LOCATION to TARGET. A 
warning will be issued if the displacement is not within 32K. Otherwise, 
the signed displacement is added to the value in LOCATION and no checking 
will be performed for this last addition^ 
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CASE 2% EXTERNAL symbol (SYM) is found (by LINK) to be absolute. 
LINK. OPERATION 

LINK will change the fixup to the following i 

LOCATION I (no change) 

PSEG^ (no change) 

TARGETS p#(SYM) ,o(SYM) -f d 

where p# and o are from a PUBLIC DECLARATIONS 
record and the sum is performed as in Case 1^ 

LOCAT E OP ERA TION : 

At LOCATE time^ LOCATE knows the following: 

a) the memory address of LOCATION 

b) the memory address of the PSEG 

c) the memory address of the PUBLIC 

Computation and checking may be performed as in Case la 
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PART 2. SEGMENT RELATIVE REFEREMCES 
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R & L enforces; 



F3VAL modulo 16 = 
FOVAL less than 64K 



PP - point defininq the PSEG which also defines FBVAL 

PT - point defininq the TARGET which also defines FOVAL (qiven PP) 
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2.1 Segments-Relative Pointer Reference (lonq call) With No Grouping and 
Both LSEG's Created In Same Translation 



A LLLLLLLLLLLLLL 



L 
L 
L 

L -f- 
L I 
L -I-- 
L 
L 



LOG 



»4. 
I- 



L 
L 
L 
L 



L 
L 
L 
LLLLLLLLLLLLLL 



B LLLLLLLLLLLLLL '^ <- PP 

L L I 

L L dl 

L L I 

L -f. 4- L V <-- PT 

.^. — >| TARGET I L 

L + . Ar L 

L L 

L L 

LLLLLLLLLLLLLL 



FIXUP. REPRESENTATION: 



LOCATIONS POINTER 

PSEGs TARGET (this is the most common choice) 

TARGET! SI(B) ,dl 

or SI(B) where dl is put in LOCATION by translator 

LINK. OPERATION I 

If LSEG B is combined, then the LINKER will modify all fixups of the 
above form that reference SI(B) by chanqinq SI(B),dl to SI(B),dl-fd2 or by 
applying d2 to the LOCATION. 



B^ ^ 

. I 

. d2 

« I 

V 

B LLLLLLLLLLLLLL '^ 
L L dl 

L + -f. L V 

L I TARGET | L => 

L 4- 4- L 

L L 

L L 

L L 

LLLLLLLLLLLLLL 



B 

9 ® 

9 e 

L L 

L + + L 

L I TARGET I L 

L + + L 

L L 

L L 

L L 

L L 
LLLLLLLLLLLLLL 



<- PP 



<- PT 
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LOCATE OPERATION! 

At LOCATE time: 

1. The BASE (FBVAL) is determined by the PSEG directive as the 

canonic PSEG defined by PP. 

2. The offset is a positive value, less than or equal to 64K, from 
the determined PSEG. LOCATE includes as part of the offset ^ FOVAL^ 
the difference between the absolute location of the LSEG and the 
absolute location of the PSEG defined by the LSEG. (This difference 
will be less than 16.) 
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2.2 Segment-Relative Pointer Reference (lonq call) With No Grouping 
Where Reference is to an EXTERNAL Symbol 

A LLLLLLLLLLLLLL ?...... <- pp 

L L • • 

L -f— .^ .+ ' L . <- PT 

L I LOG I ~- ->. SYM . . 

L + . -+ L 

L L ■ . 

LLLLLLLLLLLLLL 

F I X£P_ R E P RES^ENTAT 1 0^ : 

LOCATION: POINTER 

PSEG: TARGET (this is the most common choice) 

TARGET: EI(SYM) 

There are three ways in which an EXTERNAL segment-relative reference 
may be resolved: 

CASE 1: EXTERNAL symbol (SYM) is found (by LINK) to be in' the same 
LSEG as the reference^ 

CASE 2: EXTERNAL symbol (SYM) is found (by LINK) to be in a 
different LSEG, B. 

CASE 32 EXTERNAL symbol (SYM) is found (by LINK) to be absolute. 
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CASE Is EXTERNAL symbol (SYM) is found (by LINK) to be in the same 
LSEG as the reference. An example would be a reference to data (ROM 
DATA) stored in CODE segment A. 

The PSEG is then determined by LINK to be SI (A) as the default, 
since no grouping is specified. The followinq two cases may be 
found s 
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LINK will modify the fixup as follows: 



LOCATIONS same 
PSEG: SI (A) 
TARGET: SI (A) ,d3 

or SI (A) where d3 is applied to the OFFSET part of the ■ L 
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CASE 2: EXTERNAL symbol (SY!^) is found (by LINK) to be in a 
different' LSEG, B. This case becomes the same fixup described ir 
(2.1) . 

CASE 3: EXTERNAL symbol (SYM) is found (by LINK) to be absolute. 

The PUBLIC declaration record for SYM will define an absolute 
address of the form PSEG, OFFSET. LINK changes the fixup to: 



LOCATION: same 

PSEG: p#(SYM) 

TARGETS p# (SYM.) ,d (SYM) 

or p#(SYM) (where d(SYM) is applied to the LOCATION) 

Note that this fixup is complete ly r esolved by LINK. 

IJOCATE_OPE_RATION: (CASES 1 and 2) 

At LOCATE time, the absolute location of PSEG is determined. If the 
PSEG and its defininq LSEG are at different- locations^ then the 
difference, x, (which is less than 1^), is calculated. If the TARGET 
specification was primary (e.a., ''TARGET; SI(A),d3'^). then LOCATE 
can calculate the sum "d3 -f- x" ensuring ^'d3 + x < 64K". If the 
TARGET specification was secondary (e.g., ^'TARGET: SI(A)/Mr then x 
is applied to LOCATION, and this assurance is sacrificed. 
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2.3 Seqment-Relative Pointer Reference (long call) With Groupinq 

This fixup is much the same as the fixups described in (2.1) and 
(2.2). The only difference is that the PSEG is always specified _ to 
be' a' qroup base. The fixup would appear as one of the followmq 
(also see diaqraro below): 



LOCATION: POINTER 

PSEG: GI(G) 
TARGET: SI (D) ,dl 

or SI(D) where dl is applied to the LOCATION 

OR 

LOCATION: POINTER 
PSEG: GI(G) 

TARGET: EI(SYM) if SYM is external 
or EI(SYM) ,0 



PPPPPPPPPPPPPPPPPPPPPPPPP 



Group G = B, C. D 
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LLLLLLLLLLLLLLLLLLL 
LB L 

L L 
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LLLLLLLLLLLLLLLLLLL 
LC L 

L L 

L L 

L L 

LLLLLLLLLLLLLLLLLLL 

LLLLLLLLLLLLLLLLLLL 



LD 

L +^^-^- + 

>| TARGET I 

L +— ^ — -- — + 
L 



L 
L 
L 
L 
L 



<^ pp 



dl 

V <- PT 
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2.4 Segment-Relative Offset Reference (data reference) With No Grouping 
And Both LSEG's Created In The Same Translation 

Diagram in (2^1) can be used, 

FIXUP REPRESENTATION : 

LOCATION: OFFSET 

PSEG: TARGET (this is the most common choice) 

TARGET: SI(B) ,dl 

or SI(B) where dl is applied to the LOCATION 

- Note that this fixup is exactly the same as the Segment-Relative 
Pointer Reference shown in (2ol) with one exceptions the LOCATION 
requires no BASE fixup. This means one less fixup value to calculate 
at LOCATE time, A Segments-Relative Offset Reference v/ith grouping is 
exactly the same as th3 Seqment-^Relative Pointer Reference with 
grouping shown in (2.3) with the same exception mentioned above, 

NOTE: LOCATION could also be HIBYTE^ if the source code were, 
for example 

MOV AH,HIGH(SYM) 

Note that, unlike the 8080 R & L^ this fixup will take into account 
the final location of SYM. If SYM has the value 190H as an offset 
within its LSEG which is to be LOCATE 'd at 3680H relative to the 
PSEG, we have the followinq: 

808 R & L: 

LOCATION: 1 byte containing HIGH(SYM) = 1 

LOCATE at 3680e => LOCATION IH 

+ HIGH (3680H) = 36H 



37H 

.NJote that this value is not correct! 

8 8f_R___&^ L: 

"LOCATION: 1 byte containing zero 
Fixup record: 2 bytes containing 190H 

LOCATE at 35800 => Fixup value: 190H 

+ Base Address 3^80H 



3^3 10H 
38H is then applied to the LOCATION (HIBYTE) 
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2.5 Segment Relative Base Reference (used for segment register 
initialization) 

This fixup is much the same as the Segment-Relative Pointer 
Reference described in (2.1). The only difference is that the offset 
part, FOVAL, of the fixup is not required. 

FIXUP REPRESENTATIOM: 

LOCATION: BASE 
PSEG: TARGET 
TARGET: SI(B) 

This allows the base address (canonic PSEG) of LSEG B to be used. 
OR 

LOCATION: BASE 
PSEG: TARGET 
TARGET: EI(SYM) 

This allows the base address (canonic PSEG) of LSEG containing SYM to 
be used^ 

OR 

LOCATION: BASE 
PSEG: TARGET 
TARGET: GI (G) 

This allows the base address (canonic PSEG) of first LSEG in the 
group G to be used® 
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